View Full Version : SQL - Create Table X/Y Angabe Satzformat
Hallo,
wie erstelle ich denn mit dem interaktiven SQL eine PF mit einem anderen Satzformatsnamen als die Datei selbst? Wo kann ich das angeben? Vielen Dank im Voraus
Du erstellst die Tabelle mit Satz-Format-Name und benennst sie anschliessend um.
CREATE TABLE MySchema/MyFormat .....
RENAME TABLE MySchema/MyFormat TO SYSTEM NAME MYTable
Eine andere Möglichkeit gibt es in SQL nicht! Sonst bleibt Dir nur DDS.
Birgitta
Hallo,
ich kenne da nur den Work around die Tabelle mit dem Formatnamen zu erstellen und dann zu renamen (so war das, meine ich mich zu erinnern), aber wozu soll das eigentlich gut sein?
mfg
Dieter Bender
Hallo,
wie erstelle ich denn mit dem interaktiven SQL eine PF mit einem anderen Satzformatsnamen als die Datei selbst? Wo kann ich das angeben? Vielen Dank im Voraus
Danke ihr beiden für die fixe Antwort. Dann mache ich das so. Danke und schönes Wochenende.
Gruß
Sascha
@Dieter
Damit erspare ich mir das dauernde Umbenennen in RPG ;)
Allerdings: Warum mache ich CREATE TABLE um anschließend in RPG doch wieder native zuzugreifen ? *grübel*
@Baldur,
da kann man doch alternativ auf das E (extern definiert) in der F Lochkarte verzichten eine EDS separat ablochen und mit
read Dateiname Datenstrukurname
die Daten schnappen, oder was sagen die RPG Hardliner dazu?
Den Scharmonz mit read Formatname, den habe ich eh nie verstanden, jaja ich weiß, MultiFormat Dateien, aber die habe ich auch nicht verstanden.
Dieter
@Dieter
Damit erspare ich mir das dauernde Umbenennen in RPG ;)
Allerdings: Warum mache ich CREATE TABLE um anschließend in RPG doch wieder native zuzugreifen ? *grübel*
RPG lehnt die Umwandlung ab, da der Name nicht eindeutig ist.
Es gibt immerhin noch DSPF's und PRTF's (multiple Formate).
Der Compiler unterscheidet da leider nicht.
@Baldur: wenn ich unter Dateiformat kein E für extern beschrieben, sondern ein F für Programm beschrieben abloche, dann ist dem Compiler der Formatname schnurz. DSPF und PRTF werden nicht mit SQL erstellt und damit tritt sowas hier nicht auf.
Dieter
RPG lehnt die Umwandlung ab, da der Name nicht eindeutig ist.
Es gibt immerhin noch DSPF's und PRTF's (multiple Formate).
Der Compiler unterscheidet da leider nicht.
Allerdings: Warum mache ich CREATE TABLE um anschließend in RPG doch wieder native zuzugreifen ? *grübel*
1. CREATE TABLE, um z.B. eine IDENTITY COLUM oder ROWID zu definieren, die beim Erstellen einen eindeutigen Wert generieren und zwar auf einem tieferen Level und sicherer als das eine RPG-Funktion könnte. Das Generieren dieser Werte klappt auch, wenn man mit native RPG einen gewöhnlichen WRITE absetzt.
2. Native RPG, weil ein CHAIN halt immer noch schneller ist, als das entsprechende Statement mit SQL auszuführen.
Birgitta
Hallo,
nicht alles was Oracle macht muss es wert sein in DB2 gekupfert zu werden. Ob diese Identity Columns halten was sie versprechen, habe ich noch nicht gesehen und das hat ja immerhin den Nachteil, dass ich nicht so ohne weiteres den Satz lesen kann, den ich gerade geschrieben habe. (Ja, ich weiß, dass es da einen Work around gibt...). Ein anderer dieser "Geheimtips", das API GENUUID jedenfalls hielt garnicht, was es versprach, funktioniert nämlich bei Multiprozessor Maschinen nur fast - und damit garnicht.
Und was die Geschwindigkeit angeht, oft gehört, aber - in erster Näherung hängt die Geschwindigkeit von der Anzahl der Zugriffe ab und da sind viele Rekord Löffel Exzess Programme eher Penner als Renner.
mfg
Dieter Bender
PS: Bei der gegenwärtigen Menge an Bugs in der Datenbank würde ich die Schlüssel Generierung nur ungern der Datenbank überlassen...
1. CREATE TABLE, um z.B. eine IDENTITY COLUM oder ROWID zu definieren, die beim Erstellen einen eindeutigen Wert generieren und zwar auf einem tieferen Level und sicherer als das eine RPG-Funktion könnte. Das Generieren dieser Werte klappt auch, wenn man mit native RPG einen gewöhnlichen WRITE absetzt.
2. Native RPG, weil ein CHAIN halt immer noch schneller ist, als das entsprechende Statement mit SQL auszuführen.
Birgitta