IBDAC: In der DB sind Leerstrings statt Null. Alternativen?

[Int3g3r]

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:

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 ; ^^

Momentan habe ich im IBExpert einen "Parsing Error" den ich nicht weg bekomme.
Ich möchte das er automatisch die Felder der Tabelle holt und alle kontrolliert:

SQL-Code:

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

Gruss Int3g3r

[dataspider]

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

[jobo]

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.