Unterschiedliche Format-ID's bei CREATE TABLE

[Peder]

Hallo Forum

ich habe das Problem, dass nach einen SQL-Create Table (RUNSQLSTM aus einer Quelle) die erzeugte Datei unterschiedliche Format-ID's auf unterschiedlichen Systemen aufweist. In den RPG-Programmen, die die Datei dann benutzen, bekomme ich dann den Fehler CPF4131 (Lvlchk *no) wollte ich nicht machen.

Die Systeme haben alle V5R4, aber trotzdem ist die FORMAT-ID unterschiedlich. Mit DSPFFD kann ich keine unterschiede an den Files feststellen. Auch die Feldanzahl und Satzlängen sind identisch. Ich habe das schon oft mit anderen Files gemacht und nie ein Problem damit gehabt.

Das einzig Besondere an dieser File ist, dass ich eine Feld mit Datenbanktyp Datum verwende(§TDATE DATE NOT NULL DEFAULT,), was aber auch nix unnormales ist.

Vielen Dank für die Hilfe
Peder

[Fuerchau]

Das ist ganz normal, da die Format-ID bei SQL eben je System unterschiedlich berechnet wird, aber innerhalb des Systems immer gleich.
Welche Faktoren dafür relevant sind, kann man nicht erfahren.
2 identische Create Tables in unterschiedliche Lib's sind eben nicht die selben sondern allenfalls die gleichen Tabellen.
Da SQL diese Format-ID aber nicht benötigt ist das für SQL auch unerheblich.

Leider hast du Pech in ILE/RPG und native IO.
Entweder, du verwendest in deinem RPG eben SQL, dann hast du die Problem da nicht oder du verwendest eben LVLCHK(*NO), was nicht so emfehlenswert ist.
Die 3. Variante ist eben, du scheppst das Table-Objekt per SAVOBJ/RSTOBJ auf das Zielsystem mit, dann behält es auch die Format-ID.

Benötigst du zur Laufzeit das Objekt ggf. in anderen Lib's, dann eben per CRTDUPOBJ kopieren.

[Peder]

Das ist ganz normal, da die Format-ID bei SQL eben je System unterschiedlich berechnet wird, aber innerhalb des Systems immer gleich.
Welche Faktoren dafür relevant sind, kann man nicht erfahren.
2 identische Create Tables in unterschiedliche Lib's sind eben nicht die selben sondern allenfalls die gleichen Tabellen.

Hallo Fuerchau
dass beim Create Table der Lib-Name o. Ä. eine Rolle spielt, glaube ich nicht, und zwar aus folgenden Gründen:
1. ich habe den Create-Table schon mit vielen Dateien gemacht, die auch später mit RPG's verarbeitet wurden. Es gab dieses Problem noch nie.
2. Es gibt bei den 6 Systemen, auf denen ich installiert habe, nur 2 verschiedene Format-ID's bei dieser betreffenden File

Das muss also einen anderen Grund haben. (PTF-Stände, SQL-Einstellungen etc.)
Ich habe mir jetzt beholfen, indem ich die Objekte mit SAV/RSTOBJ transportiert habe, ich hätte nur gerne gewusst woher das kommt, und ob ich das irgendwie abstellen kann, da meine Softwaredistribution heute auf dem versenden der SQL-Quellen mit anschliessendem RUNSQLSTM pro Datenbibliothek der Mandanten besteht.

Zur Not muss ich dann bei den betreffenden RPG's doch auf LVLCHK(*NO) gehen.

Gruss
Peder

[Fuerchau]

Nun ja, in der Vergangenheit hat sich leider gezeigt, dass man sich auf die Format-ID beim Create Table häufig nicht verlassen kann.
Dieter Bender hat da auch schon mal was zu geschrieben.

Wenn man nun eine Anwendung entwickelt, die mit CREATE TABLE Dateien erstellt, sollte diese eben auch SQL verwenden, dann gibts die Probleme nicht.

Verwenden die Programme jedoch native IO, sollten die Objekte besser mit DDS erstellt werden. Nur dann gibt's die Garantie der identischen Format-ID's.

[Peder]

Dieter Bender hat da auch schon mal was zu geschrieben.

Ich habe mir den alten Post angesehen und Pikachu hat dort einen Link abgelegt, der dieses Problem, dass nur bei date, time oder timestamp-Feldern auftritt, fixt.

Hier nochmals der Hinweis: IBM eServer iSeries Authorized Problem Analysis Reports (APAR): II14134

thx @all