PDA

View Full Version : Seltsamer Spalteninhalt



Fuerchau
22-02-08, 18:13
In einem TIME-Feld (Feldtyp T) fand ich just den Inhalt "24:00:00".

Ist das denn erlaubt ?

Beim Zugriff über den ODBC-Treiber stirbt dieser ohne Fehlermeldung, da 24:00:00 im ODBC-Datentyp Time nicht möglich ist.

Kann das mal jemand als Fehler melden ?

BenderD
22-02-08, 20:58
die SQL Reference sagt nix gegenteiliges:

Table 8. USA Time Format
USA Format
24-Hour Clock
12:01 AM through 12:59 AM
00.01.00 through 00.59.00
01:00 AM through 11:59 AM
01:00.00 through 11:59.00
12:00 PM (noon) through 11:59 PM
12:00.00 through 23.59.00
12:00 AM (midnight)
24.00.00
00:00 AM (midnight)
00.00.00

und der SQL Standard scheint da auch keine Einwände zu haben, das kann man höchstens als Treiber Bug reklamieren...

D*B



In einem TIME-Feld (Feldtyp T) fand ich just den Inhalt "24:00:00".

Ist das denn erlaubt ?

Beim Zugriff über den ODBC-Treiber stirbt dieser ohne Fehlermeldung, da 24:00:00 im ODBC-Datentyp Time nicht möglich ist.

Kann das mal jemand als Fehler melden ?

Pikachu
25-02-08, 08:11
Auch in ILE RPG ist das ein ganz normaler Wert (http://publib.boulder.ibm.com/iseries/v5r1/ic2924/books/c0925083178.htm) für ein Zeitfeld (bereits seit V3R2 (http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/qbkaqe01/2.3.5?DT=19960311160249)).

Fuerchau
25-02-08, 12:29
Tja, dann habe ich mit ODBC ja schlechte Karten, wenn ich das Feld nicht als CHAR caste.

BenderD
25-02-08, 12:44
das müsste doch im View Layer zu lösen sein


Tja, dann habe ich mit ODBC ja schlechte Karten, wenn ich das Feld nicht als CHAR caste.

Fuerchau
25-02-08, 12:54
Jein.

Das Problem ist, dass ich mit dem Feld ggf. auch rechnen muss.
24:00 Uhr ist dann aber 00:00 am nächsten Tag !

Zur Zeit wird 24:00 durch 23:59:59 ersetzt, was halt bei der Berechnung, je nachdem, eben 1 Stunde oder 1 Minute oder 1 Sekunde zu wenig liefert (es wird ja nicht gerundet).

Soviel halt zu Kompatibilität von SQL.

BenderD
25-02-08, 14:20
nawohl, bei mir tuts:
create view myview as
select .... zeitfeld + 0 minutes ...
from ...

D*B


Jein.

Das Problem ist, dass ich mit dem Feld ggf. auch rechnen muss.
24:00 Uhr ist dann aber 00:00 am nächsten Tag !

Zur Zeit wird 24:00 durch 23:59:59 ersetzt, was halt bei der Berechnung, je nachdem, eben 1 Stunde oder 1 Minute oder 1 Sekunde zu wenig liefert (es wird ja nicht gerundet).

Soviel halt zu Kompatibilität von SQL.

Fuerchau
25-02-08, 14:59
Ich meine ja auch nicht die AS/400 sonderen später in z.B. MS-Access/SQL-Server.
Bestimmte Ergebnisse berechne ich ja bereits auf der AS/400, muss die Infos jedoch lokal speichern um sie dann ggf. später anders zu verwenden.

Ein ähnliches Problem existiert auch mit dem Datum '0001-01-01', dass von Microsoft dann in '2001-01-01' umgesetzt wird.
Das kleinste Datum ist hier nämlich '0100-01-01'. Jahres Zahlen < 100 werden nämlich automtisch mit 1900 bzw. 2000 ergänzt (Grenze ist glaube ich 39).

BenderD
25-02-08, 15:17
solange man über ODBC keine updates macht, kriegt man auch das alles immer im View Layer weg (auf PFs sollte man eh nie direkt zugreifen)

D*B



Ich meine ja auch nicht die AS/400 sonderen später in z.B. MS-Access/SQL-Server.
Bestimmte Ergebnisse berechne ich ja bereits auf der AS/400, muss die Infos jedoch lokal speichern um sie dann ggf. später anders zu verwenden.

Ein ähnliches Problem existiert auch mit dem Datum '0001-01-01', dass von Microsoft dann in '2001-01-01' umgesetzt wird.
Das kleinste Datum ist hier nämlich '0100-01-01'. Jahres Zahlen < 100 werden nämlich automtisch mit 1900 bzw. 2000 ergänzt (Grenze ist glaube ich 39).