View Full Version : Cpyf und alternativer Tabellenname
Da native OS-CMD's nur 10-stellige Objektnamen kennen, kann auch nur mit 10-stelligen Namen umgegangen werden.
Da der ALIAS der Datei länger als 10 ist, kann sich das OS keinen Namen "ausdenken", da der Benutzer ja die Namen vorgibt.
Wo soll also CPYF einen langen Namen generieren, wenn doch normalerweise die Kopie ein weitgehend identisches Objekt ergibt ?
Deshalb wird der CPYF abgelehnt und man muss dann halt den "Create as Select" verwenden.
Hier gilt wieder die SQL-Konvention, die aus dem langen Namen wieder einen 10-stelligen Objektnamen generiert.
Es ist ist halt schon ein Problem, mit verschieden Methoden das selbe Objekt zu bearbeiten.
Dies gilt übrigens auch für TABLE/VIEW/INDEX-Objekte, die ich anschließend mit RecordLevel-Access verarbeiten will, wo diese Arten doch für SQL vorgesehen sind.
"Es geht doch" ist für mich in diesem Fall kein Argument.
Hallo,
jede PF hat einen 10 stelligen Namen und wenn ich einen CPYF mache gebe ich selbigen als Quelldatei an und als Zieldatei ebenfalls einen, der maximal 10 stellig ist, da gibt es keinerlei Grund einen Langnamen zu erfinden, nur weil die Quelldatei zufällig einen hatte!!!
mfg
Dieter Bender
Da native OS-CMD's nur 10-stellige Objektnamen kennen, kann auch nur mit 10-stelligen Namen umgegangen werden.
Da der ALIAS der Datei länger als 10 ist, kann sich das OS keinen Namen "ausdenken", da der Benutzer ja die Namen vorgibt.
Wo soll also CPYF einen langen Namen generieren, wenn doch normalerweise die Kopie ein weitgehend identisches Objekt ergibt ?
Deshalb wird der CPYF abgelehnt und man muss dann halt den "Create as Select" verwenden.
Hier gilt wieder die SQL-Konvention, die aus dem langen Namen wieder einen 10-stelligen Objektnamen generiert.
Es ist ist halt schon ein Problem, mit verschieden Methoden das selbe Objekt zu bearbeiten.
Dies gilt übrigens auch für TABLE/VIEW/INDEX-Objekte, die ich anschließend mit RecordLevel-Access verarbeiten will, wo diese Arten doch für SQL vorgesehen sind.
"Es geht doch" ist für mich in diesem Fall kein Argument.
Dieter, da gehe nicht ganz mit dir überein.
Der lange Name ist nun Bestandteil des Dateiobjektes (sonst könnte Save/Restore) nicht funktionieren.
CRTDUPOBJ kann das im Übrigen auch nicht.
Die Erklärung liefert übrigens der CPYF gleich mit:
Datei erstellen (CRTFILE) - Hilfetext
Gibt an, wann dieser Befehl zum Kopieren von einer physischen oder
logischen Datei benutzt wird, und ob eine physische Datei erstellt wird,
um die Daten zu empfangen, wenn die angegebene Nach-Datei nicht
vorhanden ist. Ist die Nach-Datei eine DDM-Datei (Management für
verteilte Daten), die eine nicht vorhandene ferne Datei kennzeichnet,
wird die Nach-Datei auf dem Zielsystem erstellt.
*NO
Beim Starten des Befehls muss die Zieldatei bereits vorhanden sein.
Eine physische Datei zum Empfangen der Daten wird nicht erstellt.
*YES
Ist die Zieldatei nicht vorhanden, wird eine physische Datei mit dem
bei Parameter Zieldatei (TOFILE) angegebenen Namen erstellt. Ist die
Ausgangsdatei eine SQL-Tabelle, eine SQL-Sicht oder ein SQL-Index
mit einem Feld der Art benutzerdefiniert, DataLink oder LOB (Large
Object), wird eine physische Datei erstellt, die eine SQL-Tabelle
ist. In allen anderen Fällen wird als Zieldatei eine physische
Datenbankdatei erstellt, die keine SQL-Tabelle ist. Neben den
normalen Gültigkeitsprüfungen beim Kopieren müssen folgende
Sonderbedingungen beim Kopiervorgang zum Erstellen einer Zieldatei
erfüllt sein:
also ich kann da nirgends eine Einschränkung entdecken, warum das nicht gehen soll und von Langnamen oder ähnlichem steht da ebenfalls nix...
Dieter, da gehe nicht ganz mit dir überein.
Der lange Name ist nun Bestandteil des Dateiobjektes (sonst könnte Save/Restore) nicht funktionieren.
CRTDUPOBJ kann das im Übrigen auch nicht.
Die Erklärung liefert übrigens der CPYF gleich mit:
Datei erstellen (CRTFILE) - Hilfetext
Gibt an, wann dieser Befehl zum Kopieren von einer physischen oder
logischen Datei benutzt wird, und ob eine physische Datei erstellt wird,
um die Daten zu empfangen, wenn die angegebene Nach-Datei nicht
vorhanden ist. Ist die Nach-Datei eine DDM-Datei (Management für
verteilte Daten), die eine nicht vorhandene ferne Datei kennzeichnet,
wird die Nach-Datei auf dem Zielsystem erstellt.
*NO
Beim Starten des Befehls muss die Zieldatei bereits vorhanden sein.
Eine physische Datei zum Empfangen der Daten wird nicht erstellt.
*YES
Ist die Zieldatei nicht vorhanden, wird eine physische Datei mit dem
bei Parameter Zieldatei (TOFILE) angegebenen Namen erstellt. Ist die
Ausgangsdatei eine SQL-Tabelle, eine SQL-Sicht oder ein SQL-Index
mit einem Feld der Art benutzerdefiniert, DataLink oder LOB (Large
Object), wird eine physische Datei erstellt, die eine SQL-Tabelle
ist. In allen anderen Fällen wird als Zieldatei eine physische
Datenbankdatei erstellt, die keine SQL-Tabelle ist. Neben den
normalen Gültigkeitsprüfungen beim Kopieren müssen folgende
Sonderbedingungen beim Kopiervorgang zum Erstellen einer Zieldatei
erfüllt sein:
Naja, lange Rede kurzer Sinn (auch wenns nicht da explizit steht) werden sämtliche Aliase mit kopiert und beim Alias des Dateinamen scheitert das System.
Vorschrift ist hier halt: kopiere mit SQL.
Es gibt leider nur eine Regel, wie lange Namen in kurze übersetzt werden und nicht wie vorhandene lange Namen ggf. vom System umbenannt werden sollen.
Hallo,
Wieso nochmal? ein typisches Beispiel dafür, dass eine klarere Problembeschreibung direkt zur Lösung geführt hätte.
mfg
Dieter Bender
@Baldur: Solange mir keiner dokumentiert zeigt, dass das ein Feature ist, ist das für mich ein Bug!!!
Sorry, ich war der Meinung mein Problem ausführlich genug beschrieben zu haben.
Nochmal vielen Dank für die Problemlösung.
Gruß
Joe