ASP + MSSQL-Server 2000: Problem bei Konvertierung Datum

[Christian Seehase]

Moin Zusammen,

bei einer kleinen Änderung in unserem Intranet bin ich auf Problem gestossen.
Bei dem Versuch einen neuen Datensatz einzufügen erhalte ich die FM:

Microsoft OLE DB Provider for ODBC Drivers (0x80040E07)
[Microsoft][ODBC SQL Server Driver][SQL Server]The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.

Die Datumswerte werden im Format tt.mm.yyyy übergeben (gemäss der Anzeige der POST-Daten in der Fehlermeldung)
Nehme ich zum Testen Werte bei denen tt und mm im Bereich 1 bis 12 liegen tritt das Problem auch nicht auf, es werden also bei der Konvertierung Tag und Monat vertauscht.
Ein Blick in die Tabelle bestätigt das.

Theoretisch wäre jetzt klar was das Problem ist, aber:
Die Scripte für die Entwicklung sind durch kopieren der Produktivscripte in ein entsprechendes Unterverzeichnis entstanden (auf dem gleichen Server, unterhalb des gleichen Verzeichnisses)
Anschliessend wurden noch, in einer zentralen Konfigurationsdatei (natürlich ebenfalls in den Entwicklungsbereich kopiert), die Pfade entsprechend angepasst, und der Datenbankname auf den der Testdatenbank geändert.
Diese Testdatenbank ist entstanden durch einen Backup der Produktivdatenbank und einen (erzwungenen) Restore auf die Testdatenbank.
Beide liegen auf dem gleichen Server.

Soll heissen:
Abgesehen von der Lage der Scripte in der Verzeichnisstruktur, und des Namens der Datenbank liegen keine, offensichtlichen, Unterschiede vor. (Der Vollständigkeit halber sei erwähnt, dass auf meinem Entwicklungsrechner ein System-DSN auf die Produktivdatenbank eingerichtet ist. Da ich aber von niemandem, der ohne diesen zugreift, eine Rückmeldung über Fehler erhalten habe, sehe ich hier keinen Zusammenhang.)
Produktiv tritt das Problem, bei identischen Testdaten, aber nicht auf.
Ausserdem spielt es keine Rolle, ob ich von intern oder von extern (über das Internet) zugreife. Die produktive Version läuft.
(die Entwicklungsversion kann ich nicht von extern testen)

Ich konnte auch leider keine Möglichkeit finden das Datumsformat für die Datenbank zu konfigurieren.

Hat irgendjemand eine Idee, wo hier der Fehler steckt?

[EDIT]
Was ich noch vergessen hatte:
In der Produktivdatenbank stehen die Werte auch korrekt im Format tt.mm.jjjj
[/EDIT]

[Bernhard Geyer]

Was für eine Art von Script ist das? Etwas selbst Programmiert es.
Generell ist es von vorteil alle parameter immer mittels parametrisierter Abfragen in die Datenbank zu "schieben". Damit hat man die gerinsten Konvertierungsprobleme (eigentlich keine mir bekannten)
Sowas ist z.B. bei Access 'ne Katastrophe. Je nach Zugriffsweg (ohne parametrisierte Abfragen) muß das Datum in anderen Format bereitgestellt werden

[Christian Seehase]

Moin Berhard,

ja, es sind selbstentwickelte Scripte, allerdings nicht von mir, ich muss sie "nur" pflegen.

Zitat von Bernhard Geyer:

Je nach Zugriffsweg (ohne parametrisierte Abfragen) muß das Datum in anderen Format bereitgestellt werden

Könntest Du mir bitte mal ein Beispiel geben, wie Du das meinst?

[Bernhard Geyer]

Bei Access mußt man Teilweise mit # das Datum einklammern. Aber das war Access und noch problematischer als der MS-SQL-Server und sollte nur ein Hinweis auf die Probleme von Nicht-parametriesierten Anweisungen geben.

[shmia]

Aus der Online-Hilfe (Thema "Internationale Transact-SQL-Anweisungen")
Wenn Sie Datumseingaben in Vergleichen oder als Eingabe in INSERT- oder UPDATE-Anweisungen angeben, verwenden Sie Konstanten, die in allen Spracheinstellungen gleich interpretiert werden:
ADO-, OLE DB- und ODBC-Anwendungen sollten folgende ODBC-Timestamps und folgende ESCAPE-Klauseln für Datum und Zeit verwenden:

Code:

{ ts'yyyy-mm-dd hh:mm:ss[.fff] '} wie z. B.: { ts'1998-09-24 10:02:20' }
{ d'yyyy-mm-dd'} wie z. B.: { d'1998-09-24' }
{ t'hh:mm:ss'} wie z. B.: { t'10:02:20'}

Anwendungen, die andere APIs oder Transact-SQL-Skripts, gespeicherte Prozeduren und Trigger verwenden, sollten unstrukturierte Zeichenfolgen verwenden (zum Beispiel yyyymmdd für 19980924).

Anwendungen, die andere APIs oder Transact-SQL-Skripts, gespeicherte Prozeduren und Trigger verwenden, sollten die CONVERT-Anweisung mit dem expliziten Parameter style für alle Konvertierungen zwischen den Datentypen date und smalldate und Zeichenfolgen-Datentypen einsetzen. Die folgende Anweisung wird beispielsweise für alle Verbindungseinstellungen für Sprach- oder Datumsformate gleich interpretiert:

SQL-Code:

SELECT *
FROM Northwind.dbo.Orders
WHERE OrderDate = CONVERT(DATETIME, '7/19/1996', 101)

[Christian Seehase]

Moin Andreas,

danke für die Info, da hatte ich wohl die falschen Suchbegriffe

Aber warum funktioniert dann ein Script auf der einen Datenbank problemlos, und auf der anderen, die ja nur eine Kopie der funktionierenden ist, nicht?

[shmia]

Zitat von Christian Seehase:

Aber warum funktioniert dann ein Script auf der einen Datenbank problemlos, und auf der anderen, die ja nur eine Kopie der funktionierenden ist, nicht?

Das könnte z.B. von der Spracheinstellung des DB-User abhängen.
Bei der Kopie werden die Sicherheitseinstellungen bei Backup/Restore nicht mitgenommen
und schon ist ein kleiner Unterschied da.
Du kannst mit
SELECT @@LANGUAGE AS 'Language Name' die Sprache abfragen, falls du der Sache auf den Grund gehen willst.

[Christian Seehase]

Moin Andreas,

Zitat von shmia:

Das könnte z.B. von der Spracheinstellung des DB-User abhängen.

danach habe ich auch schon gesucht, konnte aber nichts dazu finden.
Allerdings ist der User, der per Connection String angegeben wird, in beiden Fällen auch gleich eingerichtet.

[Christian Seehase]

Moin Zusammen,

so, für alle, die ein vergleichbares Problem haben:

Man gebe im Connection String einfach noch zusätzlich die gewünschte Sprache an, z.B.:

"DSN=MyDB;uid=MyUser;pwd=MyPW;language=deutsch "