SQL Update aufgrund Werte einer 2. Datei

[Fuerchau]

So genau habe ich mir deinen SQL nicht angesehen.
Aber du hast Recht:

- Textkonstanten in einfache Hochkomma
- Feldnamen in doppelte Hochkomme, wenn sie nicht Namenskonform sind (z.B. "Auftrags.Nr.")

[FNeurieser]

Danke Dir nochmals recht herzlich für Deine Unterstützung.

LG
Franz-Georg

[malzusrex]

So genau habe ich mir deinen SQL nicht angesehen.
Aber du hast Recht:

- Textkonstanten in einfache Hochkomma
- Feldnamen in doppelte Hochkomme, wenn sie nicht Namenskonform sind (z.B. "Auftrags.Nr.")

Man solle auch Feldnamen in Hochkomma setzen, die z.B. USER oder so heisen.
Mir es mal passiert, das ich im SQL aus einer Datei alle meine Sätze löschen wollte (Delete from MyFile where USER = 'ICH'). Am Ende waren alle Sätze aus der Datei raus, da er sich im SQL bei USER auf die Sitzung bezogen hat..

Gruß
Ronald

[B.Hauser]

Man solle auch Feldnamen in Hochkomma setzen, die z.B. USER oder so heisen.
Mir es mal passiert, das ich im SQL aus einer Datei alle meine Sätze löschen wollte (Delete from MyFile where USER = 'ICH'). Am Ende waren alle Sätze aus der Datei raus, da er sich im SQL bei USER auf die Sitzung bezogen hat..

Gruß
Ronald

Spalten-Namen, die reservierten Worten (z.B. USER, YEAR) entsprechen, sollten/müssen IMMER in " (Gänsefüßchen) angegeben werden.
Dabei muss berücksichtigt werden, dass die Angabe in Großbuchstaben erfolgen muss. Durch das Einbetten in Hochkommata können Spalten oder Correlation-Namen, die "eigentlich" nicht erlaubt sind, verwendet werden (z.B. "Stunden/Tag")

Birgitta

[FNeurieser]

Aha,

danke für die Infos. Zwar hab ich bis jetzt das in dieser Form noch nicht benötigt, aber gut zu wissen!

[Pikachu]

Wie ist das, wenn irgendwann mal weitere Wörter reserviert werden und eine spezielle Bedeutung erhalten? SQL entwickelt sich ja weiter. Kann's dann sein, daß ein SQL-Befehl plötzlich was ganz anderes macht (mehr aktualisiert oder löscht) als vorher?

[BenderD]

Wie ist das, wenn irgendwann mal weitere Wörter reserviert werden und eine spezielle Bedeutung erhalten? SQL entwickelt sich ja weiter. Kann's dann sein, daß ein SQL-Befehl plötzlich was ganz anderes macht (mehr aktualisiert oder löscht) als vorher?

Einfache Frage - einfache Antwort: JA, und das ist umso wahrscheinlicher, je weniger man sich an den Standard hält und Sonderlocken des eigenen Dialektes verwendet, wie Naming *SYS, Commit *NONE, ORDER by im Subselect, Views mit ORDER by ...

D*B