Exception aus Datenbank getString("datum")
Yonah
wegbekomme:
In eine Datenbank mit Zelle vom Typ Datum steht 0000-00-00 drinne. Sobald
ich mit rs (Typ ResultSet) rs.getString("datum") drauf zugreifen will, kommt
folgende Exception:
SQLException: Value '0000-00-00' can not be represented as java.sql.Date
SQLState: S1009
VendorError: 0
java.sql.SQLException: Value '0000-00-00' can not be represented as
java.sql.Date
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927)
at
com.mysql.jdbc.ResultSetImpl.getDateFromString(ResultSetImpl.java:2270)
at
com.mysql.jdbc.ResultSetImpl.getStringInternal(ResultSetImpl.java:5743)
at
com.mysql.jdbc.ResultSetImpl.getString(ResultSetImpl.java:5576)
at
com.mysql.jdbc.ResultSetImpl.getString(ResultSetImpl.java:5616)
at de.autocheck.db.FZ_database.db_query(FZ_database.java:129)
Ich will ja bevor ich was weiter mache mit dem String den auch umwandeln,
aber soweit komme ich ja gar nicht :-(
Wer weiss Rat?
Gruss yonah
Yonah
Ich übergebe beim Connect: zeroDateTimeBehavior=convertToNull
und damit wandelt er das in NULL :-)
Stefan Ram wrote:
> Yonah <yo...@gmx.net> writes:
>>SQLException: Value '0000-00-00' can not be represented as java.sql.Date
>
> »0000-00-00« ist kein Datum des gregorianischen Kalenders.
> Daher sollte das Feld vermutlich den Typ »String« haben.
> (Um das sicher zu wissen, müßte man noch mal die SQL-Dokumentation
> heranziehen.)
>
> Wenn Du den Feldtyp aber nicht ändern kannst, kannst Du den Text
> ja notfalls aus dem Text der SQLException entnehmen.
>
Claus Reibenstein
> Yonah <yo...@gmx.net> writes:
>
>> SQLException: Value '0000-00-00' can not be represented as java.sql.Date
>
> »0000-00-00« ist kein Datum des gregorianischen Kalenders
... sondern der Default-Wert für Datumsfelder, die als NOT NULL
deklariert sind.
Gruß. Claus
Florian Laws
Ich bin etwas überrascht, dass NOT NULL Felder Default-Werte haben.
Ist das spezifisch für ein bestimmtes Datenbanksystem?
Viele Grüße,
Florian
Yonah Brendon Grätz
gruss yonah
Lothar Kimmeringer
> In eine Datenbank mit Zelle vom Typ Datum steht 0000-00-00 drinne.
Genauer gesagt steht da null drin.
> Sobald
> ich mit rs (Typ ResultSet) rs.getString("datum") drauf zugreifen will, kommt
> folgende Exception:
>
> SQLException: Value '0000-00-00' can not be represented as java.sql.Date
Ist ein Bug im JDBC-Treiber von MySQL. Bei einem Timestamp ist
die Fehlermeldung etwas anders, laeuft aber aufs gleiche hinaus.
> Ich will ja bevor ich was weiter mache mit dem String den auch umwandeln,
> aber soweit komme ich ja gar nicht :-(
>
> Wer weiss Rat?
String value = null;
try{
value = rs.getString("datum");
}
catch(SQLExcption se){
if (!String.valueOf(se.getMessage().equals("Value '0000-00-00' can not be
represented as java.sql.Date")){
throw se;
}
}
Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
Claus Reibenstein
> Ich bin etwas überrascht, dass NOT NULL Felder Default-Werte haben.
<http://dev.mysql.com/doc/refman/5.1/de/data-type-defaults.html>
> Ist das spezifisch für ein bestimmtes Datenbanksystem?
Im OP war von MySQL die Rede. Wie das bei anderen Datenbanken aussieht,
weiß ich nicht.
Gruß. Claus
Erhard Schwenk
> Stefan Ram schrieb:
>
>> Yonah<yo...@gmx.net> writes:
>>
>>> SQLException: Value '0000-00-00' can not be represented as java.sql.Date
>>
>
> ... sondern der Default-Wert fï¿œr Datumsfelder, die als NOT NULL
> deklariert sind.
Das kann nur mysql sein. Da lￜￜt man kein Fettnￜpfchen aus, und sei es
noch so dï¿œmmlich.
Warum sollte ein Datumsfeld, das NOT NULL deklariert ist, unbedingt
einen Default haben mï¿œssen? Und dann noch einen, der gar kein gï¿œltiges
Datum darstellt?
--
Erhard Schwenk
Akkordeonjugend Baden-Wï¿œrttemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/
Claus Reibenstein
> Am 04.09.2011 22:07, schrieb Claus Reibenstein:
>
>> Stefan Ram schrieb:
>>
>>> »0000-00-00« ist kein Datum des gregorianischen Kalenders
>>
>> ... sondern der Default-Wert für Datumsfelder, die als NOT NULL
>> deklariert sind.
>
> Das kann nur mysql sein.
Laut OP ist es MySQL.
> Da läßt man kein Fettnäpfchen aus, und sei es
> noch so dümmlich.
?
> Warum sollte ein Datumsfeld, das NOT NULL deklariert ist, unbedingt
> einen Default haben müssen?
Weil ein Feld, welches NOT NULL ist, nunmal NULL als Default nicht haben
kann?
> Und dann noch einen, der gar kein gültiges
> Datum darstellt?
Hast Du einen alternativen Vorschlag?
Ich finde den Default vollkommen in Ordnung und behandle ihn in allen
meinen Programmen entsprechend.
Gruß. Claus
Bernd Laengerich
> Weil ein Feld, welches NOT NULL ist, nunmal NULL als Default nicht haben
> kann?
Ja, und? Das ist bei anderen Feldtypen doch ebenso. Ein Feld vom Typ INT kann
doch auch NOT NULL sein. Skurril wäre es aber, wenn dann der Default 'Walter'
wäre. Ist er aber nicht, er ist 0.
> Hast Du einen alternativen Vorschlag?
Wenn es einen Default gibt, so sollte der doch einen gültigen Wert darstellen.
Oder wie fändest Du ein Feld vom Typ INT oder VARCHAR, welches bei NOT NULL
einen Default erhält, der nicht in eine String bzw. Integer-Instanz geladen
werden kann?
> Ich finde den Default vollkommen in Ordnung und behandle ihn in allen
> meinen Programmen entsprechend.
Ich finde das ist unnötige Arbeit. Entweder, das Feld kann NULL sein, weil
kein Datum dort gespeichert wird, oder das Feld muß ein Datum enthalten, dann
soll es bitteschön auch plausibel sein. Der Inhalt ist ja selbst laut
mySQL-Referenz ungültig:
"DATE
A date. The supported range is '1000-01-01' to '9999-12-31'. MySQL displays
DATE values in 'YYYY-MM-DD' format, but permits assignment of values to DATE
columns using either strings or numbers. "
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-type-overview.html
Immerhin ist der komische default, soweit ich sehe, seit 5.0.2 in strict mode
Geschichte.
Bernd
Erhard Schwenk
>
>> Am 04.09.2011 22:07, schrieb Claus Reibenstein:
>>
>>> Stefan Ram schrieb:
>>>
>>>> »0000-00-00« ist kein Datum des gregorianischen Kalenders
>>>
>>> ... sondern der Default-Wert für Datumsfelder, die als NOT NULL
>>> deklariert sind.
>>
>> Das kann nur mysql sein.
>
> Laut OP ist es MySQL.
>
>> Da läßt man kein Fettnäpfchen aus, und sei es
>> noch so dümmlich.
>
> ?
>> Warum sollte ein Datumsfeld, das NOT NULL deklariert ist, unbedingt
>> einen Default haben müssen?
> Weil ein Feld, welches NOT NULL ist, nunmal NULL als Default nicht haben
> kann?
So what?
>> Und dann noch einen, der gar kein gültiges
>> Datum darstellt?
> Hast Du einen alternativen Vorschlag?
Natürlich. Das einzig korrekte Verhalten für eine Datenbank ist, einen
INSERT ohne Wert oder SET NULL für ein NOT NULL Feld ohne Default-Wert
mit einer Fehlermeldung zu beantworten und den INSERT/UPDATE abzulehnen.
> Ich finde den Default vollkommen in Ordnung und behandle ihn in allen
> meinen Programmen entsprechend.
Krank.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
Erhard Schwenk
> Am 06.09.2011 00:51, schrieb Claus Reibenstein:
>
>> Weil ein Feld, welches NOT NULL ist, nunmal NULL als Default nicht haben
>> kann?
>
> Ja, und? Das ist bei anderen Feldtypen doch ebenso. Ein Feld vom Typ INT
> kann doch auch NOT NULL sein. Skurril wäre es aber, wenn dann der
> Default 'Walter' wäre. Ist er aber nicht, er ist 0.
Das wäre zumindest mal ein gültiger Wert. Allerdings sollte der nur dann
gesetzt werden, wenn er explizit beim Erzeugen der Spalte so festgelegt
wurde.
In eine Tabelle mit einer NOT NULL Spalte, für die kein Default
festgelegt wurde, sollte man eben auch keine Datensätze einfügen können,
ohne einen Wert für diese Spalte anzugeben.
>> Hast Du einen alternativen Vorschlag?
> Wenn es einen Default gibt, so sollte der doch einen gültigen Wert
> darstellen. Oder wie fändest Du ein Feld vom Typ INT oder VARCHAR,
> welches bei NOT NULL einen Default erhält, der nicht in eine String bzw.
> Integer-Instanz geladen werden kann?
Eben. Entweder ein explizit deklarierter, _gültiger_ Default-Wert oder
man muß eben für neue Datensätze immer einen gültigen Wert angeben.
Alles andere ist gefährlicher Unfug, der nur die Konsistenz der
Datenbank gefährdet.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
Erhard Schwenk
> Ne ich kann die DB nicht ï¿œndern, hab es jetzt aber gelï¿œst:
>
> Ich ï¿œbergebe beim Connect: zeroDateTimeBehavior=convertToNull
>
> und damit wandelt er das in NULL :-)
Ah ja. Man kann also wï¿œhlen, ob die Datenbank beim Einfï¿œgen von NULL in
eine DATE NOT NULL-Spalte die Konsistenz durch einen ungï¿œltigen
Datumswert zerbricht oder durch NULL in einer NOT NULL Spalte.
Ganz ehrlich: ich wï¿œrde mit _schnell_ ein anderes RDBMS suchen, das
wenigstens die grundlegenden Basics relationaler Datenbanken richtig macht.
--
Erhard Schwenk
Akkordeonjugend Baden-Wï¿œrttemberg - http://www.akkordeonjugend.de/
Erhard Schwenk
Wenn man mysql so nennen will: ja. Richtige Datenbanken schützen die
Konsistenz der abgelegten Daten und verweigern im Zweifelsfall den
INSERT/das UPDATE.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
Claus Reibenstein
> Am 06.09.2011 00:51, schrieb Claus Reibenstein:
>
>> Weil ein Feld, welches NOT NULL ist, nunmal NULL als Default nicht haben
>> kann?
>
> Ja, und? Das ist bei anderen Feldtypen doch ebenso. Ein Feld vom Typ INT kann
> doch auch NOT NULL sein. Skurril wäre es aber, wenn dann der Default 'Walter'
> wäre.
'Walter' kann kein Default für INT sein, '0000-00-00' für DATE aber sehr
wohl.
> Ist er aber nicht, er ist 0.
Genau, und der Null-Wert für Datumsfelder ist in MySQL '0000-00-00'.
>> Hast Du einen alternativen Vorschlag?
>
> Wenn es einen Default gibt, so sollte der doch einen gültigen Wert darstellen.
Der Wert _ist_ laut MySQL-Referenzhandbuch gültig.
> Oder wie fändest Du ein Feld vom Typ INT oder VARCHAR, welches bei NOT NULL
> einen Default erhält, der nicht in eine String bzw. Integer-Instanz geladen
> werden kann?
Lass doch bitte mal die anderen Datentypen aus dem Spiel. Hier geht es
um DATE und nichts Anderes.
>> Ich finde den Default vollkommen in Ordnung und behandle ihn in allen
>> meinen Programmen entsprechend.
>
> Ich finde das ist unnötige Arbeit.
NULL abzufragen ist mindestens genau so viel Arbeit.
'0000-00-00' ist in MySQL ein gültiger DATE-Eintrag. Eine Software, die
mit einer MySQL-Datenbank arbeitet, muss dies berücksichtigen.
> Entweder, das Feld kann NULL sein, weil
> kein Datum dort gespeichert wird, oder das Feld muß ein Datum enthalten, dann
> soll es bitteschön auch plausibel sein.
Was erscheint Dir denn an '0000-00-00' nicht plausibel?
> Der Inhalt ist ja selbst laut
> mySQL-Referenz ungültig:
Das ist falsch. '0000-00-00' ist laut MySQL-Referenz ein gültiger Wert
für DATE.
> "DATE
>
> A date. The supported range is '1000-01-01' to '9999-12-31'. MySQL displays
> DATE values in 'YYYY-MM-DD' format, but permits assignment of values to DATE
> columns using either strings or numbers. "
> http://dev.mysql.com/doc/refman/5.0/en/date-and-time-type-overview.html
,----------
| MySQL also permits you to store '0000-00-00' as a “dummy date” (if
| you are not using the NO_ZERO_DATE SQL mode).
`----------
<http://dev.mysql.com/doc/refman/5.0/en/date-and-time-types.html>
Gruß. Claus
Bernd Laengerich
> catch(SQLExcption se){
> if (!String.valueOf(se.getMessage().equals("Value '0000-00-00' can not be
> represented as java.sql.Date")){
> throw se;
> }
> }
Eine "elegante" Methode. Was machst Du wenn jemand mal ein anderes LOCALE nutzt?
Bernd
Bernd Laengerich
> 'Walter' kann kein Default für INT sein, '0000-00-00' für DATE aber sehr
> wohl.
Das ist eine Definitionssache. An der von mir zitierten Stelle ist das nicht
im erlaubten Wertebereich.
> Genau, und der Null-Wert für Datumsfelder ist in MySQL '0000-00-00'.
Hmm, ich meine daß ein DATE in mySQL durchaus NULL sein kann.
> Der Wert _ist_ laut MySQL-Referenzhandbuch gültig.
Je nach angelesener Stelle ja oder nein.
> NULL abzufragen ist mindestens genau so viel Arbeit.
Nein, NULL brauche ich nicht abzufragen, dann ist meine aus der DB geladene
Instanz eben nicht vorhanden. Aber _wenn_ da nicht NULL in der Spalte steht,
dann erwarte ich auch ein normale Objektreferenz und nicht etwas, wo ich mir
dann in einer Exceptionbehandlung den Stringwert der Spalte auf bestimmte
Merkmale untersuchen muss.
Das ganze erinnert mich an ein sehr schönes Problem in VB, welches ich mal
debuggen musste. Da kam aus einer .NET-Methode, die normalerweise eine
Referenz auf eine aus der DB geladene Instanz zurückgibt auch etwas
"komisches" heraus. Nachdem die Stelle prinzipiell abgesichert war, dennoch
eine ominöse Fehlermeldung beim Zugriff kam, lies ich das ganze im Debugger
laufen. Und es gab keine Exception beim Aufruf. Es kam auch etwas heraus. Es
war nicht "Is Nothing" Es war nicht "DbNull". Es war eine wunderschöne
Objektreferenz, leider war das zurückgegebene Objekt von der Klasse
Exception... *facepalm*
Bernd
Claus Reibenstein
> Am 06.09.2011 13:26, schrieb Claus Reibenstein:
>
>> 'Walter' kann kein Default für INT sein, '0000-00-00' für DATE aber sehr
>> wohl.
>
> Das ist eine Definitionssache.
MySQL definiert es so.
> An der von mir zitierten Stelle ist das nicht
> im erlaubten Wertebereich.
Ich habe Dir die richtige Stelle zitiert.
>> Genau, und der Null-Wert für Datumsfelder ist in MySQL '0000-00-00'.
>
> Hmm, ich meine daß ein DATE in mySQL durchaus NULL sein kann.
Aber nicht, wenn die Spalte NOT NULL ist. Genau darum geht es die ganze
Zeit.
>> Der Wert _ist_ laut MySQL-Referenzhandbuch gültig.
>
> Je nach angelesener Stelle ja oder nein.
Sorry, aber das ist jetzt albern. Die Dokumentation erwähnt diesen Wert
explizit als gültigen Wert. Die Stelle in der Dokumentation ist dabei
vollkommen irrelevant.
>> NULL abzufragen ist mindestens genau so viel Arbeit.
>
> Nein, NULL brauche ich nicht abzufragen, dann ist meine aus der DB geladene
> Instanz eben nicht vorhanden.
Und das musst Du abfangen.
> Aber _wenn_ da nicht NULL in der Spalte steht,
> dann erwarte ich auch ein normale Objektreferenz und nicht etwas, wo ich mir
> dann in einer Exceptionbehandlung den Stringwert der Spalte auf bestimmte
> Merkmale untersuchen muss.
Dann erwartest Du wohl etwas Falsches.
Gruß. Claus
Erhard Schwenk
> Bernd Laengerich schrieb:
>
>> Am 06.09.2011 13:26, schrieb Claus Reibenstein:
>>
>>> 'Walter' kann kein Default für INT sein, '0000-00-00' für DATE aber sehr
>>> wohl.
>> Das ist eine Definitionssache.
*seufz* nein.
> MySQL definiert es so.
Dann definiert MySQL falsch. Der 0.0.0000 existiert nicht, ist also kein
gültiges Datum. Und schon gar nicht für eine Spalte, die explizit NOT
NULL deklariert ist.
>> An der von mir zitierten Stelle ist das nicht
>> im erlaubten Wertebereich.
> Ich habe Dir die richtige Stelle zitiert.
>>> Genau, und der Null-Wert für Datumsfelder ist in MySQL '0000-00-00'.
Der Null-Wert für Datumsfelder sollte NULL sein und sonst nichts. Ein
Datumsfeld, das NOT NULL deklariert ist, sollte diesen exakt gar nie
annehmen.
>> Hmm, ich meine daß ein DATE in mySQL durchaus NULL sein kann.
> Aber nicht, wenn die Spalte NOT NULL ist. Genau darum geht es die ganze
> Zeit.
ACK. Wenn eine Spalte "DATE NOT NULL" deklariert ist, dann hat das RDBMS
zu jeder Zeit und in jeder Situation sicherzustellen, daß aus dieser
Spalte exakt eines kommt: ein _gültiges_, existierendes Datum.
Datenänderungen, die dazu führen, daß etwas anderes in dieser Spalte
landet, darf das RDBMS nicht ausführen, sonst ist es schlicht kaputt.
>>> Der Wert _ist_ laut MySQL-Referenzhandbuch gültig.
>> Je nach angelesener Stelle ja oder nein.
> Sorry, aber das ist jetzt albern. Die Dokumentation erwähnt diesen Wert
> explizit als gültigen Wert. Die Stelle in der Dokumentation ist dabei
> vollkommen irrelevant.
Dann ist DATE in MySQL also dokumentierterweise ungeeignet zur
Darstellung von Datumswerten? Das wird ja immer lustiger!
>>> NULL abzufragen ist mindestens genau so viel Arbeit.
>> Nein, NULL brauche ich nicht abzufragen, dann ist meine aus der DB geladene
>> Instanz eben nicht vorhanden.
> Und das musst Du abfangen.
*seufz* Nein, muß man nicht. "NOT NULL" ist genau dazu da: daß man sich
darauf _verlassen_ kann, daß man wenn man dieses Feld liest _niemals_
NULL erhält. _gar_ nie. Eben _damit_ man diesen u.U. mehr als nervigen
Zustand nicht abzufragen braucht. Es ist der Job jedes RDBMS, genau das
sicherzustellen, sonst ist es schlicht und ergreifend kaputt, völlig
unabhängig davon was irgendwelche Anfänger da in der zugehörigen
Dokumentation zusammenfabuliert haben.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
Claus Reibenstein
> Am 06.09.2011 17:23, schrieb Claus Reibenstein:
>
>> Bernd Laengerich schrieb:
>>
>>> Am 06.09.2011 13:26, schrieb Claus Reibenstein:
>>>
>>>> 'Walter' kann kein Default für INT sein, '0000-00-00' für DATE aber sehr
>>>> wohl.
>>>
>>> Das ist eine Definitionssache.
>
> *seufz* nein.
Sondern?
>> MySQL definiert es so.
>
> Dann definiert MySQL falsch.
Was heißt hier "definiert falsch"? Eine Definition ist eine Definition.
Da gibt es kein "richtig" oder "falsch".
> Der 0.0.0000 existiert nicht
Irrelevant.
>>>> Genau, und der Null-Wert für Datumsfelder ist in MySQL '0000-00-00'.
>
> Der Null-Wert für Datumsfelder sollte NULL sein und sonst nichts. Ein
> Datumsfeld, das NOT NULL deklariert ist, sollte diesen exakt gar nie
> annehmen.
Du hast leider gar nichts verstanden.
> ACK. Wenn eine Spalte "DATE NOT NULL" deklariert ist, dann hat das RDBMS
> zu jeder Zeit und in jeder Situation sicherzustellen, daß aus dieser
> Spalte exakt eines kommt: ein _gültiges_, existierendes Datum.
Falsch! Es hat ein gültiger _Wert_ zu kommen. Welche Werte gültig sind,
steht in der Dokumenation. '0000-00-00' _ist_ solch ein gültiger Wert,
also muss er berücksichtigt werden.
Was ist daran so schwer zu begreifen?
> Datenänderungen, die dazu führen, daß etwas anderes in dieser Spalte
> landet, darf das RDBMS nicht ausführen, sonst ist es schlicht kaputt.
Es arbeitet innerhalb der definierten Parameter, ist also keineswegs kaputt.
> Dann ist DATE in MySQL also dokumentierterweise ungeeignet zur
> Darstellung von Datumswerten? Das wird ja immer lustiger!
Und mir wird es jetzt zu albern.
Ihr habt es mit MySQL zu tun. MySQL lässt diesen Datumswert zu. Das ist
Fakt und wohldokumentiert. Was Ihr mit dieser Information anfangt, ist
mir egal.
Grundsätzlich sollte man sich mit den Werkzeugen, die man benutzen
möchte, auseinandersetzen und ihre Eigenheiten berücksichtigen, anstatt
irgendetwas zu fordern oder vorauszusetzen, was möglicherweise nicht
zutrifft. Ergo: Handbuch lesen!
A fool with a tool is still a fool.
Für mich ist hier EOD.
Gruß. Claus
Daniel Urban
> Am 06.09.2011 17:23, schrieb Claus Reibenstein:
>> MySQL definiert es so.
>
> Dann definiert MySQL falsch. Der 0.0.0000 existiert nicht, ist also kein
> gültiges Datum. Und schon gar nicht für eine Spalte, die explizit NOT NULL
> deklariert ist.
Das ist doch ein wenig kurz gedacht. Viele Datenbanken und
Programmiersprachen verwenden ausgezeichnete Werte für Sonderzwecke, z.B.
NaN, DBNull (.NET), "" (Oracles NULL) usw.
[...]
> Der Null-Wert für Datumsfelder sollte NULL sein und sonst nichts. Ein
> Datumsfeld, das NOT NULL deklariert ist, sollte diesen exakt gar nie
> annehmen.
Natürlich sollte das so sein, aber leider in der Praxis nicht alles so wie
es sein sollte. Insbesondere die (Un-) Datenbank MySQL verhält sich oft
nicht so wie man es von einer echten Datenbank gewohnt ist.
Gruß,
Daniel
Erhard Schwenk
> "Erhard Schwenk"
>> Am 06.09.2011 17:23, schrieb Claus Reibenstein:
>>> MySQL definiert es so.
>>
>> Dann definiert MySQL falsch. Der 0.0.0000 existiert nicht, ist also
>> NOT NULL deklariert ist.
>
> Das ist doch ein wenig kurz gedacht. Viele Datenbanken und
> z.B. NaN, DBNull (.NET), "" (Oracles NULL) usw.
daￜ andere auch murksen macht es nicht besser.
> [...]
>> Der Null-Wert fï¿œr Datumsfelder sollte NULL sein und sonst nichts. Ein
>> Datumsfeld, das NOT NULL deklariert ist, sollte diesen exakt gar nie
>> annehmen.
>
> Natï¿œrlich sollte das so sein, aber leider in der Praxis nicht alles so
> wie es sein sollte. Insbesondere die (Un-) Datenbank MySQL verhï¿œlt sich
> oft nicht so wie man es von einer echten Datenbank gewohnt ist.
Ein Datentyp, der sich "Datum" schimpft, sollte auch ein Datum enthalten
und nix anderes. Sollen sie ihn von mir aus "Hurz" nennen, dann ist das
egal. So ist das genau der Stoff, aus dem die dï¿œmlichstmï¿œglichen
Exploits entstehen.
--
Erhard Schwenk
Akkordeonjugend Baden-Wï¿œrttemberg - http://www.akkordeonjugend.de/
Lothar Kimmeringer
Das Locale setzte ich selbst. Das Property, das in dem Thread
genannt wurde, kannte ich bis dato nocht nicht, sonst haette ich
das auch gesetzt.