SQL Server – Nach Neuinstallation SQL Server Express auf Dev Rechner Fehler mit DateTime Formaten

Ich will hier kein riesen Fass zum Thema SQL DateTime Formate aufmachen, dazu gibt es schon ganz viele Fässer im Internet, die das ganz ausführlich beschreiben.

In erster Linie geht es mir in diesem Artikel darum, mir selbst eine Nachricht zu hinterlassen, was ich beim nächsten mal machen muss, wenn ich ein solches Problem nochmal habe.

Eventuell hilft der Artikel auch mal jemand anderem, der das gleiche Problem hat, wie das, welches ich nun kurz beschreibe.

Hier nun das Problem:
Nach der Einrichtung eines neuen Entwickler Rechners, natürlich mit ein wenig aktuelleren Programmversionen als es auf dem bisherigen Rechern der Fall war, bekomme ich beim Versuch eine Windows Forms Anwendung[*1] aus Visual Studio heraus zu Debuggen Fehlermeldungen, wenn ich auf die lokale Datenbank die ich auf einem SQL Server Express 64 BIT, auf dem Rechner installiert habe, zugreifen möchte.

Das Programm läuft jedoch einwandfrei wenn ich Remote auf einen anderen SQL Server zugreife.

Da ich die lokale Datenbank aus einem aktuellen Backup des Servers erstellt habe auf dem es per Remote Zugriff keine Problem gibt, schließe ich schon mal aus das meine Datenbank selbst das Problem ist.

Die Fehlermeldung lautet wie folgt:

{„Bei der Konvertierung eines varchar-Datentyps in einen smalldatetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.“}

Probleme mit der Konvertierung von DateTime Werten, deutet auf ein Problem mit falschen Formaten hin. Die Standard Formate sind abhängig von der verwendeten Sprache.

Auf dem Rechner habe ich entgegen der bisherigen Installationen eine englische SQL Server Express Version installiert und nicht wie sonst einen deutsche Version.

Sowohl auf dem Produktionsserver des Kunden als auch auf meinem „echten“ Server ist aber der SQL Server als Deutsche Version installiert.

Soll das mein Problem sein? (Und es soll sich heraus stellen, dass mein Problem wenigstens damit zusammenhängt)

Mit dem Befehl

SELECT @@LANGUAGE

kann man die aktuellen Spracheinstellungen der aktuellen Verbindung abfragen.

Die Abfrage auf meinem lokalen SQL Express Server ergibt als Antwort English.

Eine Abfrage auf den „echten“ SQL Servern ergibt jeweils Deutsch.

Bingo, da liegt das Problem. Doch wie kann ich das ändern, bzw. was ich muss ich da überhaupt ändern.

Ich muss die Standard Sprache (Default Language) des SQL Login (Benutzer) ändern.

Das kann am einfachsten über die Login Eigenschaften mit dem SQL Server Management Studio machen.

Nun möchte ich aber vermeiden, dass beim nächsten Benutzer den ich anlege wieder die „für mich“ falsche Standardsprache des Benutzers hinterlegt wird.

Die Standardsprache kann man ebenfalls mit dem SQL Server Management Studio ansehen und auch ändern.

Hierzu öffnet man die Server Eigenschaften indem man im SQL Server Management Studio im Object Explorer auf dem Knotenpunkt des Server mit der rechen Maus das Kontextmenü öffnet und dort das Eigenschaften (Property) Fenster öffnet.

Und dort stellen wir die Default Language von English auf German um. Und schon wird beim nächsten Benutzer den man anlegt die „richtige“ Standardsprache für den Benutzer hinterlegt.

Natürlich kann man auch diese Einstellungen per SQL Befehle ausführen, aber wie ich bereits am Anfang sagte, ich möchte hier kein Riesen Fass öffnen, und es gibt ganz viele die sich mit dem SQL Server besser auskennen als ich.

Eventuell ist ja ein Leser des Berichtes so SQL fit und kann die SQL Befehle oder einen direkten Link zu den Befehlen als Kommentar hinterlassen.


[*1] ja die gibt es noch und diese von der ich hier sprechen ist auch schon einige Jahre alt, bzw, wird seit Jahren immer weiter entwickelt

SQL Server Management Studio – Select Top X und Edit Top X Beschränkung

Im Microsoft SQL Server Management Studio (SQL Server 2008) werden im Kontextmenü zu Tables (Tabellen) und Views (Sichten) die beiden nachfolgenden Funktionen angeboten:

  • Select Top 1000 rows (Oberste 1000 Zeilen auswählen)
  • Edit Top 200 rows (Oberste 200 Zeilen bearbeiten)

Über den Sinn oder Unsinn warum man in einer View die Möglichkeit der Bearbeitung angeboten bekommt, möchte ich an dieser Stelle nicht weiter sprechen.

Nun ist es aber so, dass mich, diese Einschränkung stört!

Wenn ich eine Tabelle oder Sicht angezeigt bekomme,  möchte ich diese mit allen Datensätzen und nicht nur mit den ersten 1000 angezeigt bekommen.

Das gleich gilt übrigens auch für die Bearbeitung.

Nun gibt es, „Microsoft sei Dank“ die Möglichkeit, diese Einschränkung in den Optionen zum SQL Server Management Studio einstellen zu können.

Diese Option finden wir unter:

Tools -> Options -> SQL Server Object Explorer

oder für die eingefleischten Deutsch Programm Anwender:

Extras -> Optionen -> Objekt-Explorer von SQL Server

Dort finden wir  unter Table and View Options (Tabellen- und Sichtoptionen)

Die beiden Einträge:

Englische Version Deutsche Version

Nun kann man diese Werte beliebig ändern.

Oder wenn man wie ich keine Einschränkung haben möchte (alle Datensätze), kann man den Wert 0 eintragen.

Dann sieht das Kontextmenü wir folgt aus:

MS SQL Server – SQL Abfragen langsam (Sehr Langsam – dauern mehrere Minuten statt Sekundenbruchteilen)

Abfragen, in meinem Fall einige Views, haben plötzlich anstatt Sekundenbruchteile, Minuten gebraucht um ein Ergebnis zurückzugeben.
Das merkwürdigste aber daran war, wenn ich eine Datenbanksicherung auf einem anderen Server (sehr viel kleineren Server) zurückgespielt habe wurden die Abfragen wie gewohnt schnell ausgeführt.

Also lag die Vermutung nahe, dass es an diesem Server liegen muss und somit habe ich folgendes Versucht:

  • Ein Neustart des SQL Server (auch den ganzen Servers) – Kein Erfolg. 🙁
  • Festplatte des Server defragmentiert (Natürlich vorher den SQL Server Dienst beendet, damit die Datenbankdateien selbst defragmentiert werden konnten) – Kein Erfolg 🙁
  • Gesamt Konfiguration des Server mit einem Server der schnellere Ergebnisse geliefert hat verglichen (Alles OK) – Kein Erfolg 🙁
  • SQL Profiler … Nein das ist Unsinn, denn die DB (also das Backup auf einem anderen Server läuft ja bestens) – Also Arbeit gespart 🙂

Und dann bin ich auf diese Seite gestoßen und dabei auch auf den alles Entscheidenden Hinweis; die Statistiken.

Ein Aufruf der Gespeicherten Prozedur sp_updatestats hat dann den gewünschten Erfolg gehabt.

Die Abfragen geben nun wieder wie gewohnt schnelle Ergebnisse zurück.

Und falls ich damit niemand anderem helfen kann, so doch sicherlich mir selbst, wenn in einigen Monaten bei einer anderen Datenbank ein ähnliches Problem ansteht und ich dies hier schon wieder vergessen habe, und dann über meinen eigenen Blog Beitrag stolpere.