Hallo zusammen
Ich arbeite mit VB6 und diversen Datenbanken. Die Desktop-Betriebssysteme (Windows-Welt), sind z.T. englisch.
Nun habe ich immer wieder Probleme mit den Datumsfunktionen, z.B. bei Abfragen oder so.
Mal muss der Monat zuerst kommen und manchmal wieder der Tag. Die DBs sind auch nicht alle deutschsprachig.
Gibt es ein Konzept, welches generell gültig ist und dieses Datums-Chaos behebt?
Danke und Gruss
Martin
Formatiere Dein Datum das aus der Datenbank kommt.
z.B. yyyymmdd
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo
Das ist immer so eine sache mit dem Datum 
Ich habs mittlerweile aufgegeben Datumsfelder in die Datenbank zu speichern.
a.) Speichere das Datum als gleitkommazahl in die Datenbank.
Dann kannst Du mit CDate(my_gleitkommazahl) das Datum anzeigen und mit CDbl(my_date) das Datum als gleitkommazahl abspeichern.
Und was das schönste ist: es läuft einfach immer.
Nachteil: In der Datenbank steht dann nur eine Zahl die nichts aussagt.
b.) Speichere das Datum als String im Format JJJJMMTT. Vorteil: Wert ist in der Datenbank sichtabar. Jedoch musst Du das Datum mit Stringfunktionen manipulieren.
Ich würde a.) nehmen 
Gruss,
Giuseppe
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Patrik
Formatiere Dein Datum das aus der Datenbank kommt.
z.B. yyyymmdd
Das nützt eben nicht immer etwas, da ich z.B. mit englischen DBs und z.T. mit deutschen DBs arbeite.
Da ich SQL-Commands zusammensetze und dann mit Execute übergebe, müsste ich vorher immer abfragen, was die DB-Engine für eine Spräche fährt.
Gruss
Martin
Hallo zusammen
Ich arbeite mit VB6 und diversen Datenbanken. Die
Desktop-Betriebssysteme (Windows-Welt), sind z.T. englisch.Nun habe ich immer wieder Probleme mit den Datumsfunktionen,
z.B. bei Abfragen oder so.Mal muss der Monat zuerst kommen und manchmal wieder der Tag.
Die DBs sind auch nicht alle deutschsprachig.Gibt es ein Konzept, welches generell gültig ist und dieses
Datums-Chaos behebt?Danke und Gruss
Martin
Hallo Guiseppe
Danke für Deine Antwort.
Das ist eine gute Idee mit den Zahlen … aber wieso nimmst Du nicht eine Integer-Zahl?
Danke und Gruss
Martin
Weil ein Datum halt eine Gleitkommazahl ist. Die ganzen Zahlen bilden das Datum, die Stellen nach dem Komma bilden die Zeit.
Gruss
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Du musst beide Daten formatieren!
Bsp: Access
SELECT feld1 FROM table1 WHERE format(felddatum,„yyyymmdd“) = ‚format(DeinDatum,„yyyymmdd“)‘
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Patrik
Danke für Deine Antwort.
Da ich jedoch nicht mit Access arbeite, sondern mit MS-SQL 7.0 gestaltet sich das etwas schwieriger. Ich benutze zwar CONVERT auf dem Server aber das funktioniert leider nicht …
Gruss
Martin
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Ich habe noch nie mit MS-SQL 7.0 gearbeitet. Doch es funktioniert in Access, Oracle und Sybase. Von da her, könnte es auch auf MS-SQL funktionieren.
Mit Access ja, aber ich kann mir nicht vorstellen, dass Oracle oder Sybase den VB-Format-Befehl verstehen …
Ich habe noch nie mit MS-SQL 7.0 gearbeitet. Doch es
funktioniert in Access, Oracle und Sybase. Von da her, könnte
es auch auf MS-SQL funktionieren.
Selbstverständlich heisst es in Oracle und Sybase nicht „Format“…
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hi Martin!
Aufgrund deiner Frage „Warum nimmst du nicht eine Integer-Zahl“ vermute ich, daß du Programmieranfänger bist (richtig?).
Eine Integerzahl wird intern als 2-Byte-Zahl abgelegt, also zwei mal 8 Bits, wovon das höchstwertige Bit für das Vorkomma zuständig ist. Mit einem Integer kann ich somit die Zahlen von -32768 bis +32767 abbilden. Eine Zahle +32768 führt zu einem Variablen-Überlauf (Datentyp ist zu klein, Variable „platzt“).
Das heutige Datum - 20.07.2001 - ist in VB der Jahrhunderttag 37092 - diesen Wert bekommst du schon nicht mehr in eine Integer-Variable unter (ein Long mit 4 Bytes ist erforderlich).
Fließkommazahlen haben hingegen den Vorteil, daß man neben dem Datum auch die Uhrzeit unterbringen kann:
37092,25 wäre z.B. der 20.Juli 2001, 06:00 Uhr morgens
37092,50 der 20.Juli 2001, 12:00 Uhr mittags
37092,5130324074 wäre der 20.Juli 2001, 12:18:47 (plus nicht dargestellte Millisekunden)
usw.
Dies nur zu den DV-Basics, die offenbar immer mehr in Vergessenheit geraten (wer befaßt sich heute im Zeitalter interaktiver Programmierung noch mit Bitmuster, Registerinformationen oder Datentypen?) ))
Grüße
Siegfried
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Okay … werde es nochmals konsequent mit der CONVERT-Funktion (ist das Pendant zu Format) versuchen …
Gruss
Martin
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Siegried
Nein, als Anfänger würde ich mich nicht bezeichnen … habe mich wohl nur ungenau ausgedrückt. Im MS-SQL-Server ist ein Integer-Wert das selbe wie ein Long-Wert in VB.
Also ich meinte eigentlich ein Long-Wert und ich denke, da kann ich dann ohne Probleme ein heutiges Datum inkl. Uhrzeit und allem drum und dran speichern.
Meines Wissens (bin aber an dieser Stelle unsicher) werden Integer-(Long)-Werte intern schneller als Reals verarbeitet. Richtig?
Gruss
Martin
Meines Wissens (bin aber an dieser Stelle unsicher) werden
Integer-(Long)-Werte intern schneller als Reals verarbeitet.
Richtig?Gruss
Martin
Mag sein - aber das ist kaum meßbar, oder wenn, dann nur in Hochleistungsmaschinen (z.B. Cray) oder bei Rechenoperationen in gigantischen Schleifen. Vermutlich hängt es damit zusammen, daß Ganzzahlwerte direkt aus dem Bitmuster hergeleitet werden können, bei Fließkommazahlen muß das Bitmuster in Mantisse und Exponent umgewandelt und das wieder in eine reale Zahl umgerechnet werden.
Grüße
Siegfried