-
Seltsamer Spalteninhalt
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 ?
-
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
Zitat von 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 ?
-
Auch in ILE RPG ist das ein ganz normaler Wert für ein Zeitfeld (bereits seit V3R2).
-
Tja, dann habe ich mit ODBC ja schlechte Karten, wenn ich das Feld nicht als CHAR caste.
-
das müsste doch im View Layer zu lösen sein
Zitat von Fuerchau
Tja, dann habe ich mit ODBC ja schlechte Karten, wenn ich das Feld nicht als CHAR caste.
-
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.
-
nawohl, bei mir tuts:
create view myview as
select .... zeitfeld + 0 minutes ...
from ...
D*B
Zitat von 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.
-
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).
-
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
Zitat von 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).
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks