hi Tomtom, die Lösung ist ganz einfach. undef wird für den Transport als Leerstring eingetragen und damit der Empfänger das unterscheiden kann, gibt es ein zusätzliches Feld zur Deklaration: ~~~ suburb;S;; suburb;U;; ~~~ Im ersten Fall ist der Statdtteil ein Leerstring, im zweiten Fall auch aber als undef deklariert. Also wie wir das machen ist nicht die Frage, die Frage ist, obs gebraucht wird. Konkret: Brauchen wir ein zusätzliches Feld zur Deklaration? Bei diesem Bespiel sehen wir auch, das es bereits bei der Datenerhebung einen Default geben sollte für eine fehlende Angabe (nicht jede Anschrift beinhaltet einen Stadtteil). Ich kenne DB-Designer die machen sich da keine Rübe, da kommt ein suburb mit NULL daher. Genau dieses Beispiel zeigt aber auch, das es für eine weitere Verarbeitung unsinnig ist, zwischen Leerstring und NULL bzw. undef unterscheiden zu müssen. Einzig beim Klonen einer Tabelle in 1:1 sehe ich dafür eine Notwendigkeit, aber dafür gibt es fertige Lösungen. MfG

hi Tomtom, die Lösung ist ganz einfach. undef wird für den Transport als Leerstring eingetragen und damit der Empfänger das unterscheiden kann, gibt es ein zusätzliches Feld zur Deklaration: ~~~ suburb;; suburb;U;; ~~~ Im ersten Fall ist der Statdtteil ein Leerstring, im zweiten Fall auch aber als undef deklariert. Also wie wir das machen ist nicht die Frage, die Frage ist, obs gebraucht wird. Konkret: Brauchen wir ein zusätzliches Feld zur Deklaration? Bei diesem Bespiel sehen wir auch, das es bereits bei der Datenerhebung einen Default geben sollte für eine fehlende Angabe (nicht jede Anschrift beinhaltet einen Stadtteil). Ich kenne DB-Designer die machen sich da keine Rübe, da kommt ein suburb mit NULL daher. Genau dieses Beispiel zeigt aber auch, das es für eine weitere Verarbeitung unsinnig ist, zwischen Leerstring und NULL bzw. undef unterscheiden zu müssen. Einzig beim Klonen einer Tabelle in 1:1 sehe ich dafür eine Notwendigkeit, aber dafür gibt es fertige Lösungen. MfG