![]() |
Re: Kann Memofeld keinen leeren String zuweisen
Zitat:
EDIT: Mit assign(nil) und clear funktioniert es auch nicht! |
Re: Kann Memofeld keinen leeren String zuweisen
Bist Du Dir ganz sicher, dass NULL zulässig ist? Schau lieber noch einmal nach.
|
Re: Kann Memofeld keinen leeren String zuweisen
Ganz sicher! Ich kann es zum Beispiel per SQL reinschreiben. Das mach ich jetzt als Notlösung. Der User (es ist zum Glück erstmal nur einer) muss zum Leeren des Feld ein oder mehrere Leerzeichen reinschreiben. Dann mach ich OnAfterPost noch ein SQL-Update und setze das Feld auf NULL. Ziemlich bekloppt, aber das einzige, was ich jetzt machen kann.
|
Re: Kann Memofeld keinen leeren String zuweisen
Das hab ich ja noch nie gehört, aber wenn es so funktioniert :gruebel:
|
Re: Kann Memofeld keinen leeren String zuweisen
Hallo,
das Problem kommt mir bekannt vor, auch wenn's schon ein paar Jährchen her ist. Damals hat mich eine Access-DB wahnsinnig gemacht. Die Lösung war dann:
Delphi-Quellcode:
Will heißen: Der Wert einer leeren Variabel war nicht zuzuweisen, aber diese gefolgt von einem Leerzeichen funktionierte:
ADOQuery.ParamByName('Spalte').Value := leerevariabel + ' ';
Aber: In der Datenbank war dann kein Leerzeichen, sondern die Spalte wurde auf Null gesetzt. Daher dürfte der Vorschlag, der weiter oben mit dem Leerzeichen gemacht wurde, zu einer korrekten Lösung führen. Je nach Einstellung schneiden MS-SQL-Server und Access einer Zeichenfolge folgende Leerzeichen ab. Dies führt hier zu dem gewünschten Ergebnis. Es wäre also einen Versuch Wert: Vor dem Post (OnBeforePost) dem DBMemo.Text noch ein Leerzeichen hinzufügen (wenn es leer ist), damit auch in einem leeren DBMemo etwas drinne ist. Das Leerzeichen wird von der Datenbank entfernt. Zugegeben: Ist gewöhnungsbedürftig. |
Re: Kann Memofeld keinen leeren String zuweisen
Danke für die Tipps.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:03 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz