Jürgen Auer
Legendäres Mitglied
Eine merkwürdige Beobachtung fand sich Anfang der Woche bei einem Kunden:
Es gibt Spaltentypen zum Upload von Dateien. Werden diese angelegt, gibt es zusätzliche Spalten für den Mimetype, die Größe und die letzte Änderung.
Bei einem Kunden gab es mehrere Einträge, bei denen der Dateiname leer war, die anderen Spalten aber belegt waren.
Effektiv ein Bug, es war allerdings völlig unklar, wo der Fehler herkam. Tausende von Zeilen bei demselben Kunden ohne Probleme.
Erste Gegenmaßnahme: Ein Trigger auf der betroffenen Tabelle Dateien, der diesen Fall abfängt, mir eine Mail schickt und ein Rollback absetzt, so daß effektiv nichts gespeichert werden kann und ich über den Fehler informiert werde.
Trigger als Datenbankwerkzeuge sind u.a. deshalb sehr nützlich zur Fehlersuche.
Dieser Trigger schlug gestern abend an. Zusätzliche Info vom Kunden: Der Zugriff erfolgte durch ein iPad per UMTS - normalerweise sind das immer Standard-PCs, die per DSL angebunden sind.
Heute früh erneut, diesmal stand noch die Trace-Liste zur Verfügung.
Aus dieser wurde sichtbar:
Enthält eine Seite Code der Form
CODE <input type='file' id='_det.Dateien.DateiPrivate.1_file'/>
und hat der Nutzer keine Datei hochgeladen, dann schicken Standardbrowser dieses Feld leer zurück - das iPad schickt das Feld nicht zurück.
Effektiv war das ein Bug in dem Code von mir, der allerdings bis zu diesem Zeitpunkt noch nicht sichtbar geworden war und eigentlich sonst auch keine Rolle spielt. Denn wenn ein Feld eingeblendet ist und der Nutzer den Feldeintrag absichtlich löscht, soll ja auch der Datenbankinhalt gelöscht werden. Ist das Feld nicht eingeblendet, sorgen normalerweise sd:ro-value - Elemente (ro = readOnly) dafür, daß es egal ist, was der Browser schickt - der Feldinhalt wird beibehalten.
Es gibt Spaltentypen zum Upload von Dateien. Werden diese angelegt, gibt es zusätzliche Spalten für den Mimetype, die Größe und die letzte Änderung.
Bei einem Kunden gab es mehrere Einträge, bei denen der Dateiname leer war, die anderen Spalten aber belegt waren.
Effektiv ein Bug, es war allerdings völlig unklar, wo der Fehler herkam. Tausende von Zeilen bei demselben Kunden ohne Probleme.
Erste Gegenmaßnahme: Ein Trigger auf der betroffenen Tabelle Dateien, der diesen Fall abfängt, mir eine Mail schickt und ein Rollback absetzt, so daß effektiv nichts gespeichert werden kann und ich über den Fehler informiert werde.
Trigger als Datenbankwerkzeuge sind u.a. deshalb sehr nützlich zur Fehlersuche.
Dieser Trigger schlug gestern abend an. Zusätzliche Info vom Kunden: Der Zugriff erfolgte durch ein iPad per UMTS - normalerweise sind das immer Standard-PCs, die per DSL angebunden sind.
Heute früh erneut, diesmal stand noch die Trace-Liste zur Verfügung.
Aus dieser wurde sichtbar:
Enthält eine Seite Code der Form
CODE <input type='file' id='_det.Dateien.DateiPrivate.1_file'/>
und hat der Nutzer keine Datei hochgeladen, dann schicken Standardbrowser dieses Feld leer zurück - das iPad schickt das Feld nicht zurück.
Effektiv war das ein Bug in dem Code von mir, der allerdings bis zu diesem Zeitpunkt noch nicht sichtbar geworden war und eigentlich sonst auch keine Rolle spielt. Denn wenn ein Feld eingeblendet ist und der Nutzer den Feldeintrag absichtlich löscht, soll ja auch der Datenbankinhalt gelöscht werden. Ist das Feld nicht eingeblendet, sorgen normalerweise sd:ro-value - Elemente (ro = readOnly) dafür, daß es egal ist, was der Browser schickt - der Feldinhalt wird beibehalten.