Column "xxx" specified more than once

[Incocnito]

Hi Zusammen,

ich führe gerade eine Append auf eine Tabelle aus und er behauptet
"Column 'xxx' specified more than once".
Das macht meiner Meinung nach bei einer einzelnen Tabelle bzw. bei einem Append keinen Sinn.

Weiß jemand zufällig wie ich mir die tatsächlich abgeschickte SQL
(ich gehe mal davon aus, dass hier eine SQL generiert wird)
ausgeben lassen kann, damit ich wenigstens sehe was passiert?

Verrückt ist auch folgendes:
In der Tabelle sind alle Felder klein geschrieben.
Alle Felder werden in der Originalschreibweise angesprochen.
Ändere ich den Befehl von

Delphi-Quellcode:

APFAMPRU_SQL['Verfalldatum'] := DateAsNull(edVerfall.Date);

auf

Delphi-Quellcode:

APFAMPRU_SQL['verfalldatum'] := DateAsNull(edVerfall.Date);

(also mit kleinem "V") dann geht es.
Die Zeile

Delphi-Quellcode:

APFAMPRU_SQL['Status'] := nStatus;

stört ihn hierbei also von der Groß-/Kleinschreibung nicht!

Wenn er bei allen Feldern meckern würde, wäre das ja klar.
Dann wäre das einfach nur ein komischer/falscher Fehlertext.
Aber diese Konstellation verwirrt mich.
PS: Ich habe gerade nochmal nachgesehen; Es gibt tatsächlich nur ein Feld mit diesem Namen! :lol:

Verwende Delphi 10.3.2 mit Devart UniDac 8.1.3.

Vielen Dank schonmal für die Zeit und Hilfe!

Liebe Grüße
Incocnito

[hoika]

Hallo,
ich würde Dir von der Nutzung der TTable-Komponenten abraten.
Bau eine passende Query, dann siehst Du auch, was an die DB geht.

PS:
DevArt müsste auch eine TDBMonitor haben, dort kannst Du dir die geschickten Queries ansehen.

[p80286]

Zitat:

Zitat von hoika (Beitrag 1459709)

Hallo,
ich würde Dir von der Nutzung der TTable-Komponenten abraten.
Bau eine passende Query, dann siehst Du auch, was an die DB geht.

:thumb:

Zitat:

Zitat von Incocnito (Beitrag 1459704)

ich führe gerade eine Append auf eine Tabelle aus und er behauptet
"Column 'xxx' specified more than once".

Wer bitte produziert denn diese Meldung? Meist gibt es drei Verdächtige: die DB,der Treiber,die Komponente.
Ich vermute, daß da soetwas wie

Code:

update table1 set field1=x,set field2=y,set field1=z

generiert wird.
(die genae Syntax ist natürlich von Deiner DB abhängig)

Gruß
K-H

[jobo]

Probleme mit Großkleinschreibung rühren meist daher, dass im Table Create Script Hochkomma o.ä bei der Feldbenennung verwendet wurden.
Wo "findest Du die Felder in Kleinschrift"?
Schau Dir als erstes das Create Script an.

[jobo]

Nachtrag:

für Windows, Postgres 12, deutsch, Standardinstallation

Konfiguration von Postgres anpassen, um bestimmte oder alle SQL Statements zu loggen:
C:\Program Files\PostgreSQL\12\data\postgresql.conf
Zeile:

Code:

..
#log_statement = 'none'         # none, ddl, mod, all
..

Kommentarzeichen entfernen und Eintrag 'none' entsprechend der Auflistung / Bedarf anpassen.
Z.B. 'mod'
(Später wieder zurückstellen, sonst kann es schnell voll werden im System!)

Code:

..
# - Where to Log -
log_destination = 'stderr'
..

stderr ist ein Defaulteintrag, der bedeutet, dass die tatsächlich verwendeten Logfiles in der folgenden Datei explizit zu finden sind (nicht nur ein Verzeichnis):
C:\Program Files\PostgreSQL\12\data\current_logfiles
Dabei wird jeweils das konkrete, aktuell verwendete Logfile mit Tagesdatum aufgeführt.
Man landet in der Regel hier:

C:\Program Files\PostgreSQL\12\data\log\
Die Logfiles enthalten im Fehlerfall sowieso bereits SQL Statement Text und der Loglevel muss nicht geändert werden.

z.B.

Code:

..
2020-03-14 08:09:59.324 CET [5416] FEHLER:  Spalte »t_id« existiert nicht bei Zeichen 8
2020-03-14 08:09:59.324 CET [5416] TIPP:  Vielleicht wurde beabsichtigt, auf die Spalte »test.´t_id´« zu verweisen.
2020-03-14 08:09:59.324 CET [5416] ANWEISUNG:  select t_id from test
..

hier sind die Logging Infos (verwendete Version beachten!):
https://www.postgresql.org/docs/curr...g-logging.html
(btw: Postgres bietet schon seit langer Zeit diese vorbildliche, versionierte Doku)

[Incocnito]

Danke erstmal für die ganzen Ideen/Einwürfe!

Zitat:

Zitat von hoika (Beitrag 1459709)

... ich würde Dir von der Nutzung der TTable-Komponenten abraten. ...

1) Aus was für einem Grund? Dafür ist die doch entwickelt worden!
2) Ich soll in unserem Hauptprojekt die Datenbank ersetzen,
dabei versuche ich so wenig Quelltext wie möglich zu ändern.
Und da das bisher über Tabellen-Objekte lief, baue ich das so um,
dass es ebenfalls wieder so läuft. ... Naja, das ist das Ziel!

Zitat:

Zitat von hoika (Beitrag 1459709)

...
DevArt müsste auch eine TDBMonitor haben, dort kannst Du dir die geschickten Queries ansehen.

Ja tatsächlich! Danke für den Tipp! Allerdings ignoriert er die Einstellung "BeforeEvent"
scheinbar, denn er speichert die SQL nur, wenn ich den Feldnamen kleingeschrieben habe.
Schreibe ich das Feld groß, so zeigt er mit die erzeugte SQL nicht an.

Zitat:

Zitat von jobo (Beitrag 1459723)

Probleme mit Großkleinschreibung rühren meist daher, dass im Table Create Script Hochkomma o.ä bei der Feldbenennung verwendet wurden. ...

Im PgAdmin habe ich mir einfach mal mit "Select * from" alles ausgegeben und dort sind die Felder alle kleingeschrieben. Ich kann also davon ausgehen, dass das Create-Script die Feldnamen alle wandelt oder dass der PG-Server dies nachholt.

Zitat:

Zitat von jobo (Beitrag 1459724)

...
Konfiguration von Postgres anpassen, um bestimmte oder alle SQL Statements zu loggen:
C:\Program Files\PostgreSQL\12\data\postgresql.conf
Zeile:

Code:

..
#log_statement = 'none'         # none, ddl, mod, all
..

Kommentarzeichen entfernen und Eintrag 'none' entsprechend der Auflistung / Bedarf anpassen.
Z.B. 'mod'
(Später wieder zurückstellen, sonst kann es schnell voll werden im System!)

Code:

..
# - Where to Log -
log_destination = 'stderr'
..

...
Man landet in der Regel hier:
C:\Program Files\PostgreSQL\12\data\log\
...
hier sind die Logging Infos (verwendete Version beachten!):
https://www.postgresql.org/docs/curr...g-logging.html
(btw: Postgres bietet schon seit langer Zeit diese vorbildliche, versionierte Doku)

Ich hab' mir das mit den Logs mal angesehen, aber ich bekomme das so auf die schnelle nicht zum laufen. Wie du aber schon richtig geschrieben hattest werden Fehler eh geloggt.
Ich habe das Log dann in der Windows-Ereignisanzeige gefunden:

Code:

2020-03-16 12:05:46.541 CET [6356] ERROR:  column "verfalldatum" specified more than once at character 151

2020-03-16 12:05:46.541 CET [6356] STATEMENT:  INSERT INTO some_sheme.some_table
     (charge, pruefungsdatum, herstellungsdatum, lfdnr, pruefer, pzn, status, verfalldatum, verfalldatum, verfalldatum, verfalldatum)
   VALUES
     ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11)

Ich würde sagen, dass die Komponente da Mist baut, oder?
In Zusammenhang mit dem ersten Zitat würde ich aber trotzdem schauen, dass ich das ans Laufen bekomme. Das komplette Projekt auf Querys umzubauen wäre der Horror.

Liebe Grüße an alle
Incocnito

[hoika]

Hallo,
hast du auf dem Form da irgendwelche datensensitiven Elemente (TDBGrid),
wo Du Spalteneigenschaften angepasst hast (Displayformat oder sowas)?

Such mal in der DFM nach den doppelten Spaltennamen.

[Incocnito]

Die Komponente wird zur Laufzeit erstellt ohne Parent.
Diese wird dann auf dem Formular an mehreren Stellen benutzt.
Erzeuge ich eine neue Komponente und arbeite darauf, dann geht's.

Fehlersuche geht weiter ...

[jobo]

Das klingt ganz leicht nach timing / initialisierungsfehler.

Aber ohne originalen Code ist es Raterei.

[Bbommel]

Falls du nicht doch selber bei dir einen Fehler findest und ihr einen laufenden Vertrag bei DevArt habt, kann es sich lohnen, dort mal beim Support anzufragen. Ich hatte in den letzten Wochen zwei Probleme (eins lag letztlich an mir, eins war tatsächlich ein Bug in UniDac) und in beiden Fällen innerhalb weniger Stunden eine hilfreiche Antwort bekommen.