15
Problem mit Insert von DateTime in SQL2000 Server
Hallo zusammen,
habe folgende Problemstellung:
Ich muss von einer Visualisierung welche Daten von einer SPS bekommt auf eine SQL-Datenbank (SQL-2000) über ODBC zugreifen. Mein Programm habe ich auf einem deutschen SQL2005 Express Server erfolgreich getestet. Mein Kunde hat nun einen englischen 2000Server und dort funktioniert das Schreiben des Datumsformates nicht mehr.
Meine Frage dazu, das Datumsformat welches ich aus der Steuerung bekomme wird nun höchstwahrscheinlich nicht mehr zum Datumsformat vom 2000Server passen. Habe am Abend bei meinem 2005Server getestet ob ich die "CONVERT" Funktion dazu nützen kann mein DateTime auf Englisch zu meinem deutschen 2005Server zu schreiben. Dieser Test blieb jedoch erfolglos da der Export wieder funktionierte.
Warum oder weshalb funktioniert es immer beim 2005Server und nicht beim 2000Server. Interpretiert der 2005Server das DateTime Format immer in die richtige Landessprache oder was kann noch eine Ursache sein?
Sorry wenn manche Fragen für euch ganz klar sind, jedoch komme ich vom Steuerungsbereich und bin noch nicht so im SQL drinnen.
Danke für zahlreichen Antworten!
lg
NTL
habe folgende Problemstellung:
Ich muss von einer Visualisierung welche Daten von einer SPS bekommt auf eine SQL-Datenbank (SQL-2000) über ODBC zugreifen. Mein Programm habe ich auf einem deutschen SQL2005 Express Server erfolgreich getestet. Mein Kunde hat nun einen englischen 2000Server und dort funktioniert das Schreiben des Datumsformates nicht mehr.
Meine Frage dazu, das Datumsformat welches ich aus der Steuerung bekomme wird nun höchstwahrscheinlich nicht mehr zum Datumsformat vom 2000Server passen. Habe am Abend bei meinem 2005Server getestet ob ich die "CONVERT" Funktion dazu nützen kann mein DateTime auf Englisch zu meinem deutschen 2005Server zu schreiben. Dieser Test blieb jedoch erfolglos da der Export wieder funktionierte.
Warum oder weshalb funktioniert es immer beim 2005Server und nicht beim 2000Server. Interpretiert der 2005Server das DateTime Format immer in die richtige Landessprache oder was kann noch eine Ursache sein?
Sorry wenn manche Fragen für euch ganz klar sind, jedoch komme ich vom Steuerungsbereich und bin noch nicht so im SQL drinnen.
Danke für zahlreichen Antworten!
lg
NTL
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 46270
Url: https://administrator.de/contentid/46270
Ausgedruckt am: 23.11.2024 um 11:11 Uhr
15 Kommentare
Neuester Kommentar
Hallo NTL,
wenn es an den unterschiedlichen Sprachen hängt, kannst Du die einfach umstellen:
für einen Benutzer (hier z.B. sa): exec sp_defaultlanguage 'sa', 'deutsch' (oder im Enterprise Manager)
für die aktuelle Session: set language 'deutsch'
Ansonsten gibt es noch die Möglichkeit, das Datum nicht als Datum, sondern als Text zu übertragen und beim Schreiben explitit eine Umwandlung vorzunehmen. Die Quelle würde das Datum dann also z.B. in einen Text '2006-12-09 15:34:00.643' umwandeln und beim insert wird dann ein convert (datetime, @datumstext, 121) verwendet.
Gruß, Mad Max
wenn es an den unterschiedlichen Sprachen hängt, kannst Du die einfach umstellen:
für einen Benutzer (hier z.B. sa): exec sp_defaultlanguage 'sa', 'deutsch' (oder im Enterprise Manager)
für die aktuelle Session: set language 'deutsch'
Ansonsten gibt es noch die Möglichkeit, das Datum nicht als Datum, sondern als Text zu übertragen und beim Schreiben explitit eine Umwandlung vorzunehmen. Die Quelle würde das Datum dann also z.B. in einen Text '2006-12-09 15:34:00.643' umwandeln und beim insert wird dann ein convert (datetime, @datumstext, 121) verwendet.
Gruß, Mad Max
Hallo Mad Max,
danke für Deine Antwort.
Wenn ich dem Benutzer jetzt die deutsche Sprache gebe, werden dann alle Insert- und alle Select-Befehle als deutsch interpretiert?
Könnte man die Sprache beim ConnectionString mitgeben?
Das mit dem Convert habe ich auch schon gegoogelt, jedoch habe ich da noch eine kleine Frage, beim Befehl CONVERT(datetime, @datumstext, 121), steht datetime immer als jenes Format in welches ich konvertieren möchte, oder? Wird dann eigentlich jeder Text in dieses Format gedreht, oder muss dieser dann von einem bestimmten Format kommen z.b. deutsch auf englisch, ...
Danke wenn Du mir bitte noch diese kleinen Fragen beantworten könntest!
Gruß
NTL
danke für Deine Antwort.
Wenn ich dem Benutzer jetzt die deutsche Sprache gebe, werden dann alle Insert- und alle Select-Befehle als deutsch interpretiert?
Könnte man die Sprache beim ConnectionString mitgeben?
Das mit dem Convert habe ich auch schon gegoogelt, jedoch habe ich da noch eine kleine Frage, beim Befehl CONVERT(datetime, @datumstext, 121), steht datetime immer als jenes Format in welches ich konvertieren möchte, oder? Wird dann eigentlich jeder Text in dieses Format gedreht, oder muss dieser dann von einem bestimmten Format kommen z.b. deutsch auf englisch, ...
Danke wenn Du mir bitte noch diese kleinen Fragen beantworten könntest!
Gruß
NTL
Moin NTL,
a) Ja.
b) Nein. Ist eine Datenbank-Instanz-Eigenschaft, keine Connection-Eigenschaft.
c) Wie Mad Mäx schon geschrieben hat:
Gruß
Biber
a) Ja.
b) Nein. Ist eine Datenbank-Instanz-Eigenschaft, keine Connection-Eigenschaft.
c) Wie Mad Mäx schon geschrieben hat:
...also z.B. in einen Text '2006-12-09 15:34:00.643' umwandeln
sprich: der ausgelesene Text MUSS schon mit dem als dritten Parameter konform gehen, also entsprechend umgemuddelt werden.Gruß
Biber
Hi,
denke ich komme dem Ziel schon näher.
Beim ConnectionString dachte ich, man kann möglicherweise ebenfalls mitteilen, dass der Benutzer ein deutscher Benutzer ist. Dies würde einige Probleme beim Ansatz lösen.
Jetzt noch drei dumme Fragen und dann hat sich dieses Problem hoffentlich erledigt.
1. D.h., wenn ich dem Befehl "Insert ... Value ... CONVERT(datetime, meine Variable jedoch mit deutschem Format, 121)" gebe, wird mein deutsches Format als englisches in der Datenbank eingetragen?
2. Wie stellt man die Sprache um, beim Benutzer?
3. Ist dann die Oberflächensprache des Enterprise Manager ebenfalls in der eingestellten Sprache? (Nein denke ich!)
Gruß
NTL
denke ich komme dem Ziel schon näher.
Beim ConnectionString dachte ich, man kann möglicherweise ebenfalls mitteilen, dass der Benutzer ein deutscher Benutzer ist. Dies würde einige Probleme beim Ansatz lösen.
Jetzt noch drei dumme Fragen und dann hat sich dieses Problem hoffentlich erledigt.
1. D.h., wenn ich dem Befehl "Insert ... Value ... CONVERT(datetime, meine Variable jedoch mit deutschem Format, 121)" gebe, wird mein deutsches Format als englisches in der Datenbank eingetragen?
2. Wie stellt man die Sprache um, beim Benutzer?
3. Ist dann die Oberflächensprache des Enterprise Manager ebenfalls in der eingestellten Sprache? (Nein denke ich!)
Gruß
NTL
Hmmm, NTL,
ich habe nun nicht gerade einen MSSQL-Server in der Tasche, um meine Phantasien vorher auf Realitätsgehalt zu prüfen.
Deshalb nur ungetestet:
Das Format 121, das Mad Mäx ins Gespräch gebracht hat, dürfte rein formal Deinen Anforderungen am nächsten kommen.
Ist aber auch nicht das "deutsche" datetime-Format.
CONVERT-StyleId "121" sollte sein:
"yyyy-mm-dd hh:mi:ss.msecs" gleich z.B. "2006-12-09 21:06:08.080" == varchar(23)
Wenn Deine datetime-Zeichenkette nicht in diesem Format ist, sondern z.B "09.12.2006 21:06:08:080" musst Du die bei Verwendung des Formats 121 in diese Form bringen.
Denn letzten Endes funktioniert nur ein "INSERT into ... Values .. convert(datetime, "2006-12-09 21:06:08:080", 121)", jedenfalls wenn es als gültiges Datum ankommen soll. AFAIK.
Zu den "Sprachen" des Benutzers:
- eine SQL-DB hat eigentlich keine Sprache. Bestenfalls verwendete Codepages und Charsets.
Ein datetime-Wert ist schon immer gleich (intern) abgepeichert, wird aber unterschiedlich beim Client angezeigt/optisch aufbereitet.
Und wenn aber der Client mit dem Server "sprechen" will, das heißt, z.B. Datumswerte in die DB-Tabellen eintragen, dann muss er sich eben der Sprache des Servers anpassen.
Wie im richtigen Leben.
Als wenn Du mit Bill Gates mailst.
Der reagiert auch nicht, wenn Du ihm auf deutsch Hilfeangebote schreibst.
Hab ich versucht seit Windows 1.03 ...hat nix genutzt, wie alle wissen.
Gruß
Biber
ich habe nun nicht gerade einen MSSQL-Server in der Tasche, um meine Phantasien vorher auf Realitätsgehalt zu prüfen.
Deshalb nur ungetestet:
Das Format 121, das Mad Mäx ins Gespräch gebracht hat, dürfte rein formal Deinen Anforderungen am nächsten kommen.
Ist aber auch nicht das "deutsche" datetime-Format.
CONVERT-StyleId "121" sollte sein:
"yyyy-mm-dd hh:mi:ss.msecs" gleich z.B. "2006-12-09 21:06:08.080" == varchar(23)
Wenn Deine datetime-Zeichenkette nicht in diesem Format ist, sondern z.B "09.12.2006 21:06:08:080" musst Du die bei Verwendung des Formats 121 in diese Form bringen.
Denn letzten Endes funktioniert nur ein "INSERT into ... Values .. convert(datetime, "2006-12-09 21:06:08:080", 121)", jedenfalls wenn es als gültiges Datum ankommen soll. AFAIK.
Zu den "Sprachen" des Benutzers:
- eine SQL-DB hat eigentlich keine Sprache. Bestenfalls verwendete Codepages und Charsets.
Ein datetime-Wert ist schon immer gleich (intern) abgepeichert, wird aber unterschiedlich beim Client angezeigt/optisch aufbereitet.
Und wenn aber der Client mit dem Server "sprechen" will, das heißt, z.B. Datumswerte in die DB-Tabellen eintragen, dann muss er sich eben der Sprache des Servers anpassen.
Wie im richtigen Leben.
Als wenn Du mit Bill Gates mailst.
Der reagiert auch nicht, wenn Du ihm auf deutsch Hilfeangebote schreibst.
Hab ich versucht seit Windows 1.03 ...hat nix genutzt, wie alle wissen.
Gruß
Biber
Nabend, bin auch wieder da 
Nochmal zum ConnectString: Ob man die Sprache da direkt unterbringen kann, weiß ich nicht, aber für eine Session (oder Connection) kann man mit "set language 'deutsch'" die Sprache umstellen. Wenn man das kurz nach der Anmeldung abschickt ist das ja so gut wie im ConnectString.
Wenn man dem Benutzer die Sprache umstellen will, dann geht das z.B. im Enterprise Manager in den Eigenschaften des Benutzers (1. Register, ganz unten) oder mit "exec sp_defaultlanguage 'sa', 'deutsch'" (hier für den Benutzer sa).
Die Sprache des Enterprise Manager ist die, die man installiert hat, wie auch bei anderen Programmen, wie z.B. Word & Co. Prinzipiell ist der Enterprise Manager ja auch DB-unabhängig, kann also nicht aufgrund einer DB mal locker umgestellt werden. Mit "unabhängig" meine ich jetzt nicht, daß man damit auch Oracle managen kann, aber man kann mehrere SQL Server damit administrieren, von welchem sollte er dann die Einstellung verwenden?
Jetzt noch zum convert: wie Biber schon geschrieben hat, ist datetime eigentlich ein neutrales Format, eine interne Darstellung. Von SQL Server zu SQL Server ein Datum hin- und herzuschieben ist also kein Problem. Versucht jetzt aber eine Anwendung ein Datum in die DB zu schreiben, müssen die Daten irgendwie von einer internen Darstellung (z.B. .NET oder Delphi) in die interne Darstellung des SQL Server gewandelt werden. Da spielen dann so Sachen wie Ländereinstellungen für die Automatismen eine Rolle. Stellt man das Datum aber als Text dar, dann kommt eben einfach eine Zeichenfolge raus, wie '10.12.2006' oder '2006-12-10 00:43:12'. Den Text kann man rumschieben wie man will, er bleibt normalerweise gleich. Und dann konvertiert man ihn am Ziel einfach wieder in das SQL-Server-interne datetime-Format. Das geht einfach mit "convert (datetime, '10.12.2006')", dann sucht sich SQL Server wieder automatisch das möglicherweise richtige Datum raus, oder eben auch nicht. Ob SQL Server jetzt nämlich 10 als Tag und 12 als Monat sieht, oder andersrum, hängt halt wieder an Ländereinstellungen. Deshalb gibt man als dritten Parameter also genau an, wie man den Text formatiert hat. Damit die DB genau weiß, daß die Darstellung 'dd.mm.yyyy' ist, verwendet man dann 104, also: convert (datetime, '10.12.2006', 104). 121 bezeichnet die Darstellung 'yyyy-mm-dd hh:mi:ss.ms'. Andere Formate findet man in der SQL Server Hilfe unter 'CAST und CONVERT'.
Ich hoffe, wieder etwas Licht ins Dunkle gebracht zu haben.
Gruß, Mad Max
(nicht Mad Mäx
)
Nochmal zum ConnectString: Ob man die Sprache da direkt unterbringen kann, weiß ich nicht, aber für eine Session (oder Connection) kann man mit "set language 'deutsch'" die Sprache umstellen. Wenn man das kurz nach der Anmeldung abschickt ist das ja so gut wie im ConnectString.
Wenn man dem Benutzer die Sprache umstellen will, dann geht das z.B. im Enterprise Manager in den Eigenschaften des Benutzers (1. Register, ganz unten) oder mit "exec sp_defaultlanguage 'sa', 'deutsch'" (hier für den Benutzer sa).
Die Sprache des Enterprise Manager ist die, die man installiert hat, wie auch bei anderen Programmen, wie z.B. Word & Co. Prinzipiell ist der Enterprise Manager ja auch DB-unabhängig, kann also nicht aufgrund einer DB mal locker umgestellt werden. Mit "unabhängig" meine ich jetzt nicht, daß man damit auch Oracle managen kann, aber man kann mehrere SQL Server damit administrieren, von welchem sollte er dann die Einstellung verwenden?
Jetzt noch zum convert: wie Biber schon geschrieben hat, ist datetime eigentlich ein neutrales Format, eine interne Darstellung. Von SQL Server zu SQL Server ein Datum hin- und herzuschieben ist also kein Problem. Versucht jetzt aber eine Anwendung ein Datum in die DB zu schreiben, müssen die Daten irgendwie von einer internen Darstellung (z.B. .NET oder Delphi) in die interne Darstellung des SQL Server gewandelt werden. Da spielen dann so Sachen wie Ländereinstellungen für die Automatismen eine Rolle. Stellt man das Datum aber als Text dar, dann kommt eben einfach eine Zeichenfolge raus, wie '10.12.2006' oder '2006-12-10 00:43:12'. Den Text kann man rumschieben wie man will, er bleibt normalerweise gleich. Und dann konvertiert man ihn am Ziel einfach wieder in das SQL-Server-interne datetime-Format. Das geht einfach mit "convert (datetime, '10.12.2006')", dann sucht sich SQL Server wieder automatisch das möglicherweise richtige Datum raus, oder eben auch nicht. Ob SQL Server jetzt nämlich 10 als Tag und 12 als Monat sieht, oder andersrum, hängt halt wieder an Ländereinstellungen. Deshalb gibt man als dritten Parameter also genau an, wie man den Text formatiert hat. Damit die DB genau weiß, daß die Darstellung 'dd.mm.yyyy' ist, verwendet man dann 104, also: convert (datetime, '10.12.2006', 104). 121 bezeichnet die Darstellung 'yyyy-mm-dd hh:mi:ss.ms'. Andere Formate findet man in der SQL Server Hilfe unter 'CAST und CONVERT'.
Ich hoffe, wieder etwas Licht ins Dunkle gebracht zu haben.
Gruß, Mad Max
(nicht Mad Mäx
)
Hallo!
Werde mein ganzes neu erworbenes Wissen morgen testen, da ich leider zu Hause keinen englischen Server habe.
Hoffe, dass nun alle Klar- bzw. Unklarheiten diesbezüglich beseitigt sind. Werde meine Ergebnisse morgen posten.
Danke für Eure bis jetzige Hilfe!
Gruß
NTL
Werde mein ganzes neu erworbenes Wissen morgen testen, da ich leider zu Hause keinen englischen Server habe.
Hoffe, dass nun alle Klar- bzw. Unklarheiten diesbezüglich beseitigt sind. Werde meine Ergebnisse morgen posten.
Danke für Eure bis jetzige Hilfe!
Gruß
NTL
Eigentlich ist diese Geschichte lustig!
Nun wo ich alle Infos zusammengetragen habe, hab ich herausgefunden, dass mein Steuerungsprogramm den Variablenwert einer Gleitkommazahl mit "," schreibt. Dies war nun letztendlich auch die Ursache für mein Problem, da der zusammengesetzte Insert-Befehl mehr Variablen bekommen hat als angegeben.
Das Instert habe ich mit verschiedenen DateTime Formaten ". oder - oder /" getestet und hat auch funktioniert.
Trotzdem danke für die Infos!
Gruß
NTL
Nun wo ich alle Infos zusammengetragen habe, hab ich herausgefunden, dass mein Steuerungsprogramm den Variablenwert einer Gleitkommazahl mit "," schreibt. Dies war nun letztendlich auch die Ursache für mein Problem, da der zusammengesetzte Insert-Befehl mehr Variablen bekommen hat als angegeben.
Das Instert habe ich mit verschiedenen DateTime Formaten ". oder - oder /" getestet und hat auch funktioniert.
Trotzdem danke für die Infos!
Gruß
NTL
Moin NTL,
na, herzlichen Glückwunsch!
Warum habe ich eigentlich nie Montags solche Sternstunden? *grmbl*
Aber eine Rückfrage hab ich nun doch zu dem Satz:
Was heißt das?
Der String wäre auch so, wie er war als gültiges datetime-Format erkannt worden und eine String-Ummuddelei wäre überflüssig gewesen?
Sonst poste doch bitte im Ansatz, wie Du welches datetime-Format (INPUT) nun in ein gültiges dateformat(in Tabelle) gebracht hast.
Denn bisher war ja alles Theorie... die Feuerprobe in der Praxis ist ja das Spannende.
Danke
Biber
na, herzlichen Glückwunsch!
Warum habe ich eigentlich nie Montags solche Sternstunden? *grmbl*
Aber eine Rückfrage hab ich nun doch zu dem Satz:
Das Insert habe ich mit verschiedenen DateTime Formaten ". oder - oder /" getestet und hat auch funktioniert.
Was heißt das?
Der String wäre auch so, wie er war als gültiges datetime-Format erkannt worden und eine String-Ummuddelei wäre überflüssig gewesen?
Sonst poste doch bitte im Ansatz, wie Du welches datetime-Format (INPUT) nun in ein gültiges dateformat(in Tabelle) gebracht hast.
Denn bisher war ja alles Theorie... die Feuerprobe in der Praxis ist ja das Spannende.
Danke
Biber
Hi,
sorry für die Falschmeldung, da ich mit Werten kleiner 12 getestet habe wurde diese als gültig erkannt.
Ihr hattet zuvor schon Recht, man muss zuvor immer in das richtige Format wandeln.
Gruß
Thomas
sorry für die Falschmeldung, da ich mit Werten kleiner 12 getestet habe wurde diese als gültig erkannt.
Ihr hattet zuvor schon Recht, man muss zuvor immer in das richtige Format wandeln.
Gruß
Thomas
man muss zuvor immer in das richtige Format wandeln
Frau auch, wenn es Dich tröstet...Haken dran?
Gruß
Biber
Frau auch, wenn es Dich tröstet...
Sorry, aber jetzt sitze ich anscheinend jetzt auf der Leitung.
Haken dran? Nein!
Gruß
NTL
Hallo Thomas,
zu dem Wortspielchen mit man und Frau helf ich dir jetzt mal nicht weiter, aber mit dem Haken wollte Biber eigentlich nur wissen, ob Dein Problem gelöst ist, dann könntest Du dieses Thema nämlich abschließen und es würde mit einem hübschen grünen Häkchen versehen.
Gruß, Mad Max
zu dem Wortspielchen mit man und Frau helf ich dir jetzt mal nicht weiter, aber mit dem Haken wollte Biber eigentlich nur wissen, ob Dein Problem gelöst ist, dann könntest Du dieses Thema nämlich abschließen und es würde mit einem hübschen grünen Häkchen versehen.
Gruß, Mad Max
So wie es aussieht ist es gelöst.
Danke für die Hilfe!
Gruß
NTL
Danke für die Hilfe!
Gruß
NTL
Okay, okay,
meine Wortspielchen muss ich wohl dosierter einsetzen in diesem Forum ...*Notiz mach*
Was den Haken betrifft, war Mad Max' Interpretation aber richtig.
Für das nächste Mal, NTL:
Der Beitrag-Ersteller/die Beitrag-Erstellerin kann, wenn die Frage hinreichend beantwortet wurde, durch "Editieren" des Eröffnungsbeitrags und anschließendes Ankreuzen des Kontrollkästchens "Dieser Beitrag gilt als gelöst" einen grünen Haken erzeugen.
Als Zeichen für erledigt.
Dann kann ein Moderator im Anschluss den Beitrag schließen.
Andernfalls kommt Jahre später irgendein Dackel, setzt darunter einen Kommentar beginnend mit den Worten "Ich hab genau das gleiche Problem.." und erzählt dann übergangslos von seinen klemmenden NumLock-Tasten oder ähnliches.
However, jetzt setze ich "Haken" und "Schloss" und gut is'.
Schönen Feierabend
Biber
meine Wortspielchen muss ich wohl dosierter einsetzen in diesem Forum ...*Notiz mach*
Was den Haken betrifft, war Mad Max' Interpretation aber richtig.
Für das nächste Mal, NTL:
Der Beitrag-Ersteller/die Beitrag-Erstellerin kann, wenn die Frage hinreichend beantwortet wurde, durch "Editieren" des Eröffnungsbeitrags und anschließendes Ankreuzen des Kontrollkästchens "Dieser Beitrag gilt als gelöst" einen grünen Haken erzeugen.
Als Zeichen für erledigt.
Dann kann ein Moderator im Anschluss den Beitrag schließen.
Andernfalls kommt Jahre später irgendein Dackel, setzt darunter einen Kommentar beginnend mit den Worten "Ich hab genau das gleiche Problem.." und erzählt dann übergangslos von seinen klemmenden NumLock-Tasten oder ähnliches.
However, jetzt setze ich "Haken" und "Schloss" und gut is'.
Schönen Feierabend
Biber
