thomas-99
Goto Top

W2K12R2 ASP Classic - SQL Server - Datum speichern - Type mismatch

Hallo Zusammen,

wir haben ein paar ASP Projekte die von W2K8 auf W2K12R2 umgezogen sind. Alles funktioniert nur bei einer Sache, bekommen wir einen Fehler:

Provider error '80020005'
Type mismatch.

Und genau an dieser Stelle wird ein Datum in die Datenbank gespeichert. Das Datum ist korrekt, wird im Vorfeld geprüft und als String übergeben
Das Projekt läuft unter Win8 64Bit ohne Probleme, auch das Speichern des Datums.
Die MDAC Version ist bei beidenWin8 und W2K12R2- 6.3.9600.16384 - völlig identisch.
Die Einstellungen in des Systemsteuerung Datumsformat sind ebenso korrekt.

Wenn ich das Datum konvertiere klappt das Speichern. Ist allerdings ungünstig, weil das Projekt aus vielen 100 Dateien besteht und alles noch einmal umstellen - nicht wirklich!

Hat jemand eine Idee?

DANKE

Viele Grüße
Ciao Thomas

Content-ID: 258888

Url: https://administrator.de/forum/w2k12r2-asp-classic-sql-server-datum-speichern-type-mismatch-258888.html

Ausgedruckt am: 23.12.2024 um 07:12 Uhr

colinardo
colinardo 04.01.2015 aktualisiert um 16:24:10 Uhr
Goto Top
Hallo Thomas,
Wenn ich das Datum konvertiere klappt das Speichern. Ist allerdings ungünstig, weil das Projekt aus vielen 100 Dateien besteht und alles noch einmal umstellen - nicht wirklich!
wie, Ihr habt das ganze speichern in die DB nicht mit einer Funktion in eine separate Klasse ausgelagert ?? Und nun stehen alle SQL-Inserts verteilt in den Dateien, wer macht den bitte so was ?

Welchen Typ hat denn die Spalte in der Datenbank ?

Stimmt das DATEFORMAT auf dem SQL Server ? http://msdn.microsoft.com/de-de/library/ms189491.aspx

Ein bisschen Code von deiner Seite wäre auch nicht schlecht.

Grüße Uwe

p.s. Es gibt Programme für Suchen/Ersetzen in mehreren Dateien, wie z.B. UltraEdit , falls es doch erforderlich sein sollte.
thomas-99
thomas-99 04.01.2015 um 16:47:51 Uhr
Goto Top
Hi Uwe,

das ist ein komplizierter Prozess, in dem die Daten geprüft werden, mit anderen Datenbanken abgeglichen werden.
Teilweise ist alles in deinem Dic zwischengespeichert. Und am Schluss werden alle Daten in die Datenbank gespeichert.
Bis vor 2 Wochen lief das gleiche Projekt auf dem W2K8 64bit und hatte seinen Dienst getan, viele Jahre ohne Probleme.

Egal hier ein einfaches RS, was den gleichen Fehler bring, wie das komplizierte ASP:

set rs = server.createobject("adodb.recordset")
rs.open "SELECT * FROM [test] WHERE testid = 1", conn,1,3
if not rs.eof then
rs("Testdate") = "01.02.2015" ' hier kommt mein Fehler bei dem Update. Mit einem cDate("01.02.2015") klappt es.
rs("Testdate") = now() ' das klappt
rs("Testdate") = "yyyy/mm/dd" ' das klappt
rs.update
else
response.write("ERROR")
response.end
end if

rs.close
set rs = nothing

Da es unter Win8 64 bit läuft und der Kern der Selbe ist wie unter W2K12R2 muss es mit den Einstellungen am Server zu tun haben.
Habe leider keinen zweiten Server mit 2012.
Das RS erlaubt keinen String, bzw ein Datum mit "yyyy/mm/dd" auch als String wird gespeichert.
In der Systemsteuerung ist das Datum richtig eingestellt.

Noch eine Idee?

Ciao thomas
colinardo
colinardo 04.01.2015 aktualisiert um 16:55:08 Uhr
Goto Top
Das Datumsformat was ein SQL-Server akzeptiert wird wie oben bereits geschrieben auf dem SQL-Server festgelegt:
http://msdn.microsoft.com/de-de/library/ms189491.aspx
Wenn der SQL-Server also auch umgestellt wurde wurde das vermutlich vergessen.
thomas-99
thomas-99 04.01.2015 um 17:22:44 Uhr
Goto Top
nein, der SQL Server ist immer noch der alte Server. Wenn ich die VM mit dem W2K8 starte und meinen Test von oben ausführe, klappt es.
Der neue Win 2012 Server macht an der selben Stelle ärger.
Also muss es nach meinem Verständnis an dem neuen Server W2K12R2 liegen.
Oder?
Die Connection ist die gleiche, die Rollen auf dem SQL Server sind die Gleichen, alle Einstellungen sind geblieben. Das Datenbankserver ist ein W2K8 mit SQL Server 2012 64bit

Mir gehen echt die Ideen aus.

Ciao thomas
colinardo
colinardo 04.01.2015 aktualisiert um 17:32:30 Uhr
Goto Top
rs("Testdate") = "01.02.2015"
das das so überhaupt funktioniert hat grenzt an ein Wunder ... Mein Rat an dich: Ändere es ab !

Grüße Uwe