Seltsamer Spalteninhalt

[Fuerchau]

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]

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]

Auch in ILE RPG ist das ein ganz normaler Wert für ein Zeitfeld (bereits seit V3R2).

[Fuerchau]

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

[BenderD]

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]

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]

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]

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]

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).