none
Unterschiedliches Verhalten bei Typprüfungen RRS feed

  • Allgemeine Diskussion

  • Ich habe drei Server:

    1. SQL Express Version 11.0.2100.60 (aktueller Testserver für uns Entwickler)

    2. SQL Server 2012 Version 11.0.2218.03 (Live Server fürs Intranet)

    3. SQL Server 2012 Version 11.0.2100.60 (Testserver für die Migration auf neue Version des Intranets)

    Der dritte Server ist als neue Instanz vor kurzen hinzugekommen um eine neue Version unserer Intranetsoftware zu testen. Beim Übertragen von Views bin ich auf ein Problem gestoßen zu dem ich bisher keine Lösung in der Doku oder via Google finden konnte.

    Eine Abfrage wie zum Beispiel:

    select ISNULL(STARTDATUM_DT, 0) from TABLE where LID = xyz

    Funktioniert auf Server 1 und 2 problemlos, führt auf Server 3 jedoch zu folgendem Fehler:

    Meldung 206, Ebene 16, Status 2, Zeile 1
    Operandentypkollision: int ist inkompatibel mit datetime2

    Die Abfrage ist natürlich nur ein vereinfachtes Beispiel, es gibt noch mehr Code bei uns der in Msg206 verendet. Mir ist klar, dass man das ganze durch Änderungen in den Abfragen ändern könnte. Allerdings gibt es dutzende Views und vor allem noch viele Abfragen die direkt in Java eingebaut sind, was es extrem unpraktisch macht, alle Konstellationen die zu diesem Fehler führen zu finden und auch zu beheben.

    Ich gehe derzeit davon aus, dass es irgendeine Einstellung gibt, die auf dem neuen Server 3 eine härtere Typprüfung erzwingt. Leider war ich nicht im Stande die entsprechende Einstellung zu finden, denn alles was ich bisher gesehen habe scheint gleich konfiguriert zu sein, Kompatibilitätsmodus steht bei allen Servern auf SQL 2008 (110). Aber dennoch muss es bei Server 3 einen Unterschied geben.

    Freitag, 11. Oktober 2019 06:07

Alle Antworten

  • Hi,

    kann es sein, dass die Spalte STARTDATUM_DT auf dem neuen Server datetime2, auf den anderen aber datetime ist? Falls ja, würde das den Fehler erklären, der ist dann aber IIRC nicht änderbar, außer ihr stellt das wieder um oder passt die Abfragen entsprechend an.

    Was passiert, wenn Du einfach mal eine Datenbanksicherung vom Livesystem auf das Testsystem überträgst?


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Freitag, 11. Oktober 2019 06:29
    Moderator
  • Stefan, datetime und datetime2 haben quasi die gleiche Data type precedence (Transact-SQL), beide weit vor integer; das würde es eher nicht erklären.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]


    Freitag, 11. Oktober 2019 07:28
  • Hallo ,

    schau doch bitte auf den ersten beiden Servern ob dort ein STARTDATUM_DT mit dem Inhalt NULL vorhanden ist.
    Das sollte es tun:
    select count(*) from TABLE
    where 

    STARTDATUM_DT is null
    and 
    LID = xyz
    Ich schätze mal das ist nicht der Fall. 
    Dann zeigt der 3. Server das nur weil deine Daten es so hergeben, weil dort STARTDATUM_DT= NULL existiert.
    Grüße Alexander

    Freitag, 11. Oktober 2019 07:39
  • Hi,

    kann es sein, dass die Spalte STARTDATUM_DT auf dem neuen Server datetime2, auf den anderen aber datetime ist? Falls ja, würde das den Fehler erklären, der ist dann aber IIRC nicht änderbar, außer ihr stellt das wieder um oder passt die Abfragen entsprechend an.

    Was passiert, wenn Du einfach mal eine Datenbanksicherung vom Livesystem auf das Testsystem überträgst?


    Erste Versuche legen nahe, dass es tatsächlich daran liegt. Zumindest bekomme ich den Fehler nicht mit einem neu angelegten Datumsfeld mit datetime statt datetime2. Dass muss ich aber noch eingehender austesten.


    • Bearbeitet Godfilla Freitag, 11. Oktober 2019 07:44
    Freitag, 11. Oktober 2019 07:42
  • Hallo ,

    schau doch bitte auf den ersten beiden Servern ob dort ein STARTDATUM_DT mit dem Inhalt NULL vorhanden ist.
    Das sollte es tun:
    select count(*) from TABLE
    where 

    STARTDATUM_DT is null
    and 
    LID = xyz
    Ich schätze mal das ist nicht der Fall. 
    Dann zeigt der 3. Server das nur weil deine Daten es so hergeben, weil dort STARTDATUM_DT= NULL existiert.
    Grüße Alexander

    Daran liegt es definitiv nicht. Die hier gezeigte Abfrage ist auch nur ein Beispiel, tatsächlich habe ich viel mehr Code die zu Operandentypkollision führt unabhängig vom Vorhandensein von Daten in den Feldern.
    Freitag, 11. Oktober 2019 07:44
  • Hallo Olaf,

    mit datetime würde die Abfrage aber funktionieren, mit datetime2 nicht. (Zumindest auf meiner SQL Server 2017 Testinstanz, die ich grade hier habe)

    DECLARE @Source TABLE ( DateChanged datetime, DateChanged2 datetime2 );
    
    INSERT INTO @Source ( DateChanged, DateChanged2 )
    VALUES ( '20190101', NULL ),
           ( NULL, '20190101' )
    
    SELECT ISNULL( DateChanged, 0 )
    FROM   @Source
    
    SELECT ISNULL( DateChanged2, 0 )
    FROM   @Source


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Freitag, 11. Oktober 2019 07:51
    Moderator
  • DateTime entspricht noch dem alten VB/OLE-Type Date, der als Doublewert gespeichert wurde und somit 0 = 30.12.1899 ist. Außerdem kann der nur Jahre 100 - 9999 und keine Millisekunden. Jahre kleiner 100 werden automatisch nach der 1940-Regel in 19xx bzw. 20xx erweitert, was einem spätestens am 1.1.2040 auf die Füße fällt.
    DateTime2 hingegen ist ein echter Date-Type der ausschließlich DateTime's enthalten kann, und somit nicht in Double konvertiert werden kann.

    Was die weiteren Typkollisionen angeht, so kann es ja auch sein, dass ihr bei der Übernahme der DDL's auch hier Typeanpassungen vorgenommen habt.

    Freitag, 11. Oktober 2019 08:26