Nach Umstellung von DBX auf FireDac wird im String nach ! alles beim abgeschnitten

[Byteteufel]

Hallo zusammen,

ich habe da eine seltsames Problem. Meine Anwendung lief unter DBX mit MSSQL und Firbird problemlos. Dann habe ich mit Seattle auf FireDac umgestellt. Erst schien alles problemlos zu laufen, jetzt habe ich festgestellt, dass bei einem Update und bei einem Insert in die Tabellen bei Strings alles inkl. dem Ausführzungszeichen abgeschnitten wird. Beim Lesen aus der Tabelle ist aber alles vorhanden, wenn ein Ausführungszeichen im String steckt. Beim Zurückspeichern verschwindet dieses inkl. der folgenden Zeichen.

Beispiel:
Ein String hat den Inhalt 'Das ist ein Test! Gefolgt von mehr Inhalt'

Im Debugger kann ich sehen, dass der FDBQuery auch in der Insert oder Update Anweisung die Zeichenkette komplett übergeben wird.
In der Datenbank steht dann aber nur noch 'Das ist ein Test' alles was inkl. '! Gefolgt von mehr Inhalt'

Bei dem bei Seattle mitgeliefertem Beispiel funktioniert aber der Insert in die Datenbank.

Hat jemand eine Idee, was das sein könnte? Ich habe mir bereits einen Wolf gesucht.

Danke für Eure Tipps.

Viele Grüße

Axel

[jaenicke]

Benutzt du denn Parameter? Dann sollte das nicht passieren, denn dafür sind sie ja da.

Oder baust du den SQL-Text als String komplett zusammen? Das sollte man vermeiden.

[Byteteufel]

Hallo Sebastian,

ich baue den String zur Laufzeit zusammen. Bisher klappte es immer problemlos.
Aber wieso verhält es sich dann hier anders?

Ich werde es mal mit Parameter an einer Stelle ausprobieren und dann berichten.

Danke schon mal für den Hinweis.

Viele Grüße

Axel

[Byteteufel]

Hallo Sebastian,

in der Tat, mit den Parametern klappt es. Aber wieso ist es denn unterschiedlich? Als SQL-Statement kommt am Server jeweils das selbe an.

Gibt es noch eine Möglichkeit, den SQL-String mit aufgelösten Parametern sich anzeigen zu lassen? Vorher hatte ich DBQuery.sql.text dazu verwendet. Nutze ich es, dann stehen da nur die Parameter drin. Wo kann ich aber den echten SQL-String mit aufgelösten Parametern sehen?

Viele Grüße

Axel

[mkinzler]

Die Parameter werden erst auf dem Server auf die vorbereitete (prepared) Abfrage angewandt.

[himitsu]

Hattest du die "Strings" auch ordentlich korrekt gequoted, bevor sie in den SQL-Text eingebaut wurden?

[Andidreas]

Hi,

ich hab bei mir gerade das folgende SQL Statement getestet:
qryFireDAC.SQL.Add(' insert into TESTFIREDAC (ID, FIELD1) values(:ID, ''Hallo! Welt'') '); der String "Hallo! Welt" kam in der DB richtig an...
Evtl. hängt dein Problem auch mit den den ResourceOptions MacroCreate & MacroExpand zusammen, da hier das Ausrufezeichen für die Suche nach Makros verwendet wird (FireDAC Doku).

Zitat von Byteteufel:

... Gibt es noch eine Möglichkeit, den SQL-String mit aufgelösten Parametern sich anzeigen zu lassen? ...

FireDAC bietet die Möglichkeit ein Tracing zu aktivieren, ob du darüber die gewünschten Infos bekommt kann ich nicht versprechen, ein Versuch wär es aber vielleicht wert... Das Tracing kannst Du wie folgt aktivieren...

In den Parametern der TFDConnection den folgenden Eintrag hinzufügen:
conFireDAC.Params.Add('MonitorBy=Remote'); Auf deiner Form bzw. auf deinem Datenmodul die FireDAC Komponente TFDMoniRemoteClientLink hinzufügen und hier die Option "Tracing" auf "True" setzen...

Bevor du jetzt dein Projekt startest musst du die FDMonitor.exe gestartet haben, diese kannst Du entweder über die IDE starten (zumindest hab ich in Delphi7 ein Menü für FireDAC wo ich den Monitor starten kann) alternativ findest Du die FDMonitor.exe im Installationsverzeichnis der FireDAC.
Der FDMonitor zeigt dir nun etwas detailierter die Informationen welche er mit der DB austauscht...

Vielleicht helfen dir die Infos...

[ConnorMcLeod]

Ist die Länge von dem Tabellenfeld groß genug?

[Uwe Raabe]

Zitat von Andidreas:

Evtl. hängt dein Problem auch mit den den ResourceOptions MacroCreate & MacroExpand zusammen, da hier das Ausrufezeichen für die Suche nach Makros verwendet wird (FireDAC Doku).

Der Link ging nicht ganz an die richtige Stelle. Dieser hier passt etwas besser: Substitutionsvariablen

Abgesehen davon sollte man immer mit Parametern arbeiten.