Fehlersuche bei select mit IBDAC

[messie]

Moin,

nachdem ich eines der zuletzt geposteten Probleme mit einem sinnvollen und zeitlich gut erträglichen Join-Konstrukt lösen kann (mir ist da eben mal ein Kronleuchter aufgegangen) hapert es an der Umsetzung.

Code:

SELECT distinct TIME_STAMP FROM AUFTRAG 
join SUBORDER on AUFTRAG.ID = SUBORDER.ORDER_ID 
join COMPONENT on SUBORDER.ID = COMPONENT.BATCH_ID 
join SUBCOMPONENT on COMPONENT.ID = SUBCOMPONENT.PUMP_ID 
join DATA ON SUBCOMPONENT.ID = MEASURED_DATA.SUBCOMPONENT_ID 
where AUFTRAG.INTERNAL_ORDER = '123456'

Dieser Code funzt wunderbar im FlameRobin, nicht aber in meiner Anwendung. Ich bekomme bei selbiger Abfrage an meine TIBCQuery eine Exception "conversion error from string", die auf den ersten Eintrag in ORDER zeigt.

Was muss ich da beachten?

Grüße, Messie

[Union]

ORDER ist IMHO ein reserviertes Schlüsselwort. Also "ORDER" schreiben.

[tsteinmaurer]

Besitzen die Felder in den JOIN Bedingungen den gleichen Datentyp?

[messie]

Zitat von tsteinmaurer:

Besitzen die Felder in den JOIN Bedingungen den gleichen Datentyp?

Ja, das sind echte Indices. Nur der TIME_STAMP und die INTERNAL_ORDER sind Strings.

Zitat von Union:

ORDER ist IMHO ein reserviertes Schlüsselwort. Also "ORDER" schreiben.

In der echten DB heißt das auch anders. Da ist nur ein Firmenname drin, den ich rausgenommen habe. Ich habe das mal ersetzt.

Grüße, Messie

[Union]

Sind die sonstigen Randbedingungen die selben? Z.b. die Version der fbclient, usw.? Andere Idee wäre eine Parametrisierung der Auftragsnummer.

[hoika]

Hallo,

Zitat:

where AUFTRAG.INTERNAL_ORDER = '123456'

wie gross ist das Feld INTERNAL_ORDER in der DB ?

Zitat:

Dieser Code funzt wunderbar im FlameRobin, nicht aber in meiner Anwendung.

Zeigt dir FlameRobin auch die Datensätze an?
Wenn nicht, hast du ihm nur ein Prepare/Open machen lassen,
aber die Datensätze nicht abgeholen lassen.

"Conversion Error From String" kann auch heißen,
dass du in deine DB einen String eingetragen hast, der Längenmäßig nicht in das Feld reinpasst
z.B: Feld mit VarChar(1), in das "AB" eingetragen wurde.
Dummerweise merkt das FB erst beim Abholen der Datensätze, dass das gar nicht passt.

Mach mal ein Select * auf alle verwendeten Tabellen und hole auch die Datensätze alle ab.


Heiko

[Lemmy]

Zitat von hoika:

"Conversion Error From String" kann auch heißen,
dass du in deine DB einen String eingetragen hast, der Längenmäßig nicht in das Feld reinpasst
z.B: Feld mit VarChar(1), in das "AB" eingetragen wurde.
Dummerweise merkt das FB erst beim Abholen der Datensätze, dass das gar nicht passt.

wie schafft man das? Ich kenne das nur von der Situation, dass jemand per "Update" auf die Systemtabellen an den Tabellenstrukturen herum spielt und dann genau so ein Konstrukt fabriziert....

Grüße

[tsteinmaurer]

Da gibt es einen Bug in Verbindung mit UTF8. http://tracker.firebirdsql.org/browse/CORE-3373

[messie]

Zitat von hoika:

Hallo,
Zeigt dir FlameRobin auch die Datensätze an?

"Conversion Error From String" kann auch heißen,
dass du in deine DB einen String eingetragen hast, der Längenmäßig nicht in das Feld reinpasst
z.B: Feld mit VarChar(1), in das "AB" eingetragen wurde.

Moin,

die Datensätze sind in FlameRobin da. Bei der Auslegung der Stringlängen war ich sehr großzügig und habe varchar(100) verwendet trotz Stringlängen bisher <= 25. Da ist eigentlich auch noch Luft für UTF8. Und im Moment lese ich ja nur.

Grüße, Messie


Edit: ich habe die Abfrage jetzt hinbekommen - es waren banale Fehler - tut mir leid!


Danke für die Unterstützung, ich werde sicher in Kürze noch weitere Fragen haben.