![]() |
Datenbank: Firebird • Version: 2.x • Zugriff über: IBDAC
IBDAC: In der DB sind Leerstrings statt Null. Alternativen?
Hallo,
ich verwende die IBDAC-Komponenten von Devart um auf Firebird zuzugreifen. Leider habe ich erst jetzt gemerkt, dass leere Strings/Null-Werte nicht richtig behandelt werden. Wenn ich das hier verwende
Code:
wird das Feld mit einem leeren String gefüllt. Ich möchte aber Null im Feld stehen haben. Das passiert auch wenn ein leeres DB-Edit gepostet wird. Alle mir bekannten Kompoenten z.B. BDE oder IBX schreiben in diesen Fällen Null in die DB. Darauf ist meine ganze Anwendung ausgelgegt (2 Mio Zeilen). Ich verwenden oft Code wie if IBCTable1.FieldByName('myField').isNull
IBCTable1.FieldByName('myField').AsString := '';
Das funktioniert nun natürlich nicht mehr wie gewüscht, da IBDAC Leerstrings und nicht Null in die DB schreibt. Jetzt meine ganze App mit allen SQL-Statements zu ändern ist zu umständlich. Wer kennt Lösungen? Ich hab den Wunsch schon an IBDAC herangetragen, doch da passiert seit Monaten nichts in der Richtung. Wer kennt eine gute Alternative zu IBDAC (Firebird 2.x, Unicode), die in den genannten Fällen Nullwerte schreibt? |
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
Code:
IBCTable1.FieldByName('myField').Clear;
|
AW: IBDAC Leerstring statt Null. Alternativen?
Ich kenne Deine Komponenten nicht aber IMHO sollte
IBCTable1.FieldByName('myField').Clear auch bei Dir gehen |
AW: IBDAC Leerstring statt Null. Alternativen?
Ist mE auch eigentlich korrekt, da ein Leerstring in einer DB vorkommen darf.
Man kann ein Feld in der DB auch definieren, dass dort ein Leerstring nicht zugelassen ist, wäre möglich, dass IBDAC das auch berücksichtigt (Leerstring erlaubt -> '', nicht erlaubt -> NULL) |
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
AsString ist für deinen Fall schlecht.
Code:
wäre als Beispiel eine Möglichkeit. Und Clear (wie bereits erwähnt) sollte es auch tun.
IBCTable1.FieldByName('myField').Value := Null;
Frank |
AW: IBDAC Leerstring statt Null. Alternativen?
Hi,
Zitat:
Zitat:
Vorschlag:
Code:
funktioniert, also einfach nach ".AsString := '';" Suchen und durch ".Clear;" ersetzen. Wird schneller gehen, also die Bibliothek auszutauschen....
IBCTable1.FieldByName('myField').Clear;
GRüße |
AW: IBDAC Leerstring statt Null. Alternativen?
Oder schreib dir einen Trigger, der '' durch NULL ersetzt vor dem Einfügen/Update setzt
|
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
Wenn man anfängt, seine nachlässige Programmierung durch Trigger in der DB abzufangen, sträuben sich bei mir die Haare. Man sollte bei allen Lösungen sich auch die Frage stellen, ob es die saubere Lösung ist. Frank |
AW: IBDAC Leerstring statt Null. Alternativen?
Guten Tag,
Ich stehe gerade vor dem selben Dilemma. Ich möchte keine Leerstrings in meiner DB. Entweder hat ein Feld ein Zeichen, was kein Leerzeichen ist, oder es ist auf Null gesetzt. Ist es möglich im BeforPost die Leerstrings zu ersetzen ? Es wir ja das DataSet mitgegeben ist es nicht möglich die Leerstrings mit Null zu ersetzen? Freundliche Grüsse Int3g3r |
AW: IBDAC Leerstring statt Null. Alternativen?
Betrifft das auch IBDAC? Ich frage nur, weil FireDAC eine Option StrsEmpty2Null hat, die vermutlich genau diesen Effekt aktiviert.
|
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
EDIT: Hab hier ne mögliche Lösung. Also bei mir Funktionierts. :-D
Delphi-Quellcode:
procedure Tdm.qryTestBeforePost(DataSet: TDataSet);
var i: Integer; begin for i := 0 to DataSet.FieldCount-1 do begin if (DataSet.FieldByName(DataSet.FieldList[i].DisplayName).ReadOnly) or (DataSet.FieldByName(DataSet.FieldList[i].DisplayName).IsNull) then Continue; if trim(DataSet.FieldByName(DataSet.FieldList[i].DisplayName).AsString) = '' then DataSet.FieldByName(DataSet.FieldList[i].DisplayName).Clear; end; end; end; |
AW: IBDAC Leerstring statt Null. Alternativen?
Du solltest zum Einen überprüfen, ob du das Feld überhaupt beschreiben darfst, und zum Anderen, ob es nicht schon NULL ist. Auch ein NULL-Wert liefert einen Leerstring bei AsString.
|
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
Das hätte irgendwann ne Exception gegeben.:roll: Wurde nun angepasst! |
AW: IBDAC Leerstring statt Null. Alternativen?
Alternativ könntre man dies auch mit einem Trigger lösen; wäre dann unabhängig von den Komponenten/Programm.
|
AW: IBDAC Leerstring statt Null. Alternativen?
Statt
Delphi-Quellcode:
kannst du dich auch gleich
TrimRight(TrimLeft(...
Delphi-Quellcode:
schreiben, oder?
Trim(...
|
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
Habe gedacht aus " Hallo Welt " würde danach "HalloWelt" Zitat:
|
AW: IBDAC Leerstring statt Null. Alternativen?
Hatte ich schon vorher gelesen. Da ich mich mit der FireBird-Syntax noch schlechter auskenne als in Delphi, habe ich mir gedacht ich lasse das lieber.
Ist einfach
SQL-Code:
SET TERM ^^ ;
CREATE TRIGGER <TABELLE>_BI FOR <TABELLE> ACTIVE BEFORE INSERT or UPDATE POSITION 0 AS begin if ( new.<Feld> = '') then new.<Feld> = NULL; end ^^ SET TERM ; ^^ |
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
|
AW: IBDAC Leerstring statt Null. Alternativen?
Hallo,
Zitat:
Null = Wert nicht bekannt "" = Wert bekannt, ist aber leer. |
AW: IBDAC Leerstring statt Null. Alternativen?
Es gibt noch eine Möglichkeit: Wert bekannt und kein Leerstring, besteht aber nur aus Leerzeichen.
So wie ich das verstanden habe, ist diese Vorgabe <Leerstring> => NULL hier anwendungsspezifisch. |
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
Sicherlich kann es für andere Anwendungen Sinn machen wenn man wissen will ob je ein Eintrag gemacht wurde oder nicht. Für meine Anwendung ist dies aber nicht relevant. |
AW: IBDAC Leerstring statt Null. Alternativen?
Hallo,
Zitat:
|
AW: IBDAC Leerstring statt Null. Alternativen?
Man kann das Feld in Firebird ja auch mit einem Default belegen, der dann ein Leerstring ist.
|
AW: IBDAC Leerstring statt Null. Alternativen?
Moin...8-)
Zitat:
|
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
(Betreff des Threads ist etwas missverständlich) |
AW: IBDAC Leerstring statt Null. Alternativen?
Ich versuche nun gerade auf der Datenbankseite dies zu realisieren.
Mir ist folgendes Beispiel zu umständlich, ich möchte nicht jedes Feld manuell im Trigger eintragen müssen:
SQL-Code:
Momentan habe ich im IBExpert einen "Parsing Error" den ich nicht weg bekomme.
SET TERM ^^ ;
CREATE TRIGGER <TABELLE>_BI FOR <TABELLE> ACTIVE BEFORE INSERT or UPDATE POSITION 0 AS begin if ( new.<Feld> = '') then new.<Feld> = NULL; end ^^ SET TERM ; ^^ Ich möchte das er automatisch die Felder der Tabelle holt und alle kontrolliert:
SQL-Code:
Gruss Int3g3r
CREATE OR ALTER trigger "_TBTEST_BI0" for "_TBTEST"
active before insert position 0 AS declare variable field_name varchar(255); begin for select rdb$field_name from rdb$relation_fields where rdb$relation_name=upper('_TBTEST') into :field_name do begin if (new.:field_name = '') then new.:field_name = NULL; --new.:field_name (Parsing error!) end end |
AW: IBDAC: In der DB sind Leerstrings statt Null. Alternativen?
Der Doppelpunkt ist nicht so universell einsetzbar wie sich das mancher wünscht.
Der ist halt für Parameter - nicht zum Basteln eines Statements. Du kannst IMO nur eine SP (als Beispiel: sp_check_emty_strings) schreiben, welche als Parameter den Tabellenname und den PrimaryKey-Wert bekommt. In des SP baust du das Statement als string und führst das Statement mit execute statement ... aus. In der Tabelle benötigst du dann einen AFTER INSERT OR UPDATE Trigger. Im Trigger steht dann nur noch: execute procedure sp_check_emty_strings('TABELLENNAME', new.id) Frank |
AW: IBDAC: In der DB sind Leerstrings statt Null. Alternativen?
Also, ich weiß nicht, ob es eine gute Idee ist, einen solchen generalisierten Trigger so einzusetzen.
Dynamisch alle Felder auf Null abzuklappern bedeutet in der Praxis: - ignorieren von Key field Definitionen? - schlechtere Performance - Intransparenz Die Verwendung optionaler Fremdschlüssel oder auch die Verwendung von PK und nicht optionalen FK erfolgt auf Basis allgemein verwendeter und notwendiger Vorgehen bei Modelierung und Datenverarbeitnug. NULL/ Not NULL ist fester Bestandteil im Umgabng mit Schlüsselfeldern und Fremdschlüsseln. Das sollte man nicht überformen. Jedes Insert oder Update muss die Felder aus dem Dictionary auslesen, darüber loopen und mit den Eingangsdaten abgleichen. Das kostet Zeit. Insertanweisungen werden intransparent "verbogen". Das ist mit Triggern leider immer so und man sieht es einem Tabellenfeld nicht an. Wenn man sowas trotzdem machen möchte, wäre es vielleicht sinnvoller, statische Trigger herzunehmen, deren Code man meinetwegen anhand des Models generiert. Hier würde man gezielt alle Keyfields ausnehmen und auch alle Zahlenfelder, sowie alle not null Felder. Außerdem könnte man Constraints einsetzen, die Leerstrings als Inhalt verbieten. |
AW: IBDAC Leerstring statt Null. Alternativen?
Zitat:
Btw. Für
Code:
gibt es eine eigene Anweisung
IF (feld = '') feld = NULL;
Code:
Ist quasi das Gegenstück zu COALESCE.
feld = NULLIF(feld, '');
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:41 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