JetBrains 0xDBE verbindet sich nicht mit SQLExpress

Wer versucht sich auf einer Standardinstallation eines SqlExpress Server mit dem Datenbank Tool 0xDBE von Jetbrains zu verbinden wird leider nicht sofort Erfolg haben.
Es gibt 2 kleine Hürden die man zuerst überwinden muss, die ich hier in diesem Artikel beschreiben möchte.

TCP/IP Protokoll aktivieren

Bei der Standardinstallation eines SQLExpress ist das TCP/IP Protokoll nicht aktiviert, um mit 0xDBE arbeiten zu können muss das TCP/IP Protokoll aktiviert werden.
Hierzu öffnen wir den "Sql Server Configuration Manager" (danach nicht schließen wir brauchen ihn noch einmal), wählen auf der linken Seite den SQL Server aus, welchen wir konfigurieren wollen und aktivieren auf der rechtern Seite das TCP/IP Protokoll (siehe nachfolgende Abbildung).


Wenn die Sache mit dem TCP/IP Protokoll sicherlich noch von vielen als selbstverständlich angesehen wird und bereits aktiviert wurde ist der zweite Schritt sicherlich der entscheidende und nicht so offensichtliche.

SQL Server Browser

Bei einer Standardinstallation des SQLExpress Server wird der Dienst "SQL Server Browser“ installiert, aber weder ativiert noch gestartet.
Um mit 0xDBE eine Verbindung mit einem SQLExpress Server herzustellen ist es aber notwendig dass dieser Dienst läuft.
Hierzu gehen wir wie folgt vor:
Wir öffnen wieder (oder besser noch wir haben ihn noch auf) den "Sql Server Configuration Manager".


Wählen auf der linken Seite die "SQL Server Services" aus und doppelklicken auf der rechten Seite auf den "SQL Server Browser"


Dort wählen wir den Karteireiter „Service" aus und ändern den "Start Mode" von „Disabled" auf „Automatic".
Abschließend starten wir noch den Dienst "SQL Server Browser".

Nun klappt es auch mit 0xDBE und dem SQLExpress!

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 Transaktionsprotokoll verkleinern (sichern) – SQL 2005 – SQL 2008

Bereits vor 6 Jahren (wie die Zeit vergeht) hatte ich in einem Artikel „SQL 2000 Transaktionsprotokoll verkleinern“ beschrieben wie man ein zu groß gewordenes Transaktionsprotokoll verkleinern kann.

Da die neuere Version SQL 2008 nicht mehr über die Option WITH TRUNCATE_ONLY verfügt, funktioniert die beschrieben Methode nicht mehr.

Nachfolgend möchte ich daher eine alternative Method vorstellen, welche den gleichen  gewünschten Effekt hat.

Das verkleinern des Transaktionsprotokolls.

Damit die Verkleinerung des Transaktionprotokolls nicht zu problemen bei einer eventuellen Rücksicherung führt, würde ich vor dem verkleinern unbedingt eine Sicherung der Datenbank und des Transaktionsprotokolls durchführen. Denn nur die Sicherung des Transaktionsprotokolls ermöglicht auch das spätere verkleinern.

Hier also nun der Transakt SQL Code zur Speicherung der DB und des Logs mit anschließendem Verkleiner der Transaktionsprotokoll Datei.

USE pubs
BACKUP DATABASE pubs TO DISK='C:\SqlDataBackup\pubs.bak' WITH INIT
BACKUP LOG pubs_log TO DISK='C:\SqlDataBackup\pubs_log.bak' WITH INIT
DBCC SHRINKFILE(pubs_Log, 10)
GO

Am besten kann man das in einer Batch Datei (Kommando Stapeldatei) einbauen und z. B. regelmäßig als Tast auf dem Rechner laufen lassen.
Wer das regelmäßig ausführen möchte kann das auch in eine Batch Datei packen und von der Kommandozeile ausführen. Was übrigens auch dann als Task ausgeführt werden kann.

@ECHO OFF
set SQL_UTIL_HOME="%ProgramFiles%\Microsoft SQL Server\100\Tools\Binn\osql"
rem Tragen Sie in der nachfolgenden Zeile den Namen des SQL Server ein z.B. (localhost)
set SQL_SERVERNAME=localhost
rem Tragen Sie in der nachfolgenden Zeile den Namen der zu sichernden Datenbank ein
set SQL_DBNAME=pubs
set SQL_LOGNAME=pubs_log
rem Tragen sie den Namen inkl. Pfad der Backup Datei ein
set SQL_BACKUP_FILE='C:\SqlBackup\pubs.BAK'
set SQL_LOG_FILE='C:\SqlBackup\pubs_log.BAK'
@ECHO ON
@ECHO Datenbank sichern
%SQL_UTIL_HOME% -S%SQL_SERVERNAME% -E -n -Q "BACKUP DATABASE %SQL_DBNAME% TO DISK = %SQL_BACKUP_FILE% WITH INIT;"
@ECHO Protokolldatei sichern
%SQL_UTIL_HOME% -S%SQL_SERVERNAME% -E -n -Q "BACKUP LOG %SQL_DBNAME% TO DISK = %SQL_LOG_FILE% WITH INIT;"
@ECHO Protokolldatei verkleinern
%SQL_UTIL_HOME% -S%SQL_SERVERNAME% -E -n -d%SQL_DBNAME%  -Q "DBCC SHRINKFILE(%SQL_LOGNAME%, 10)"

Wenn man nun noch ein Backup Programm wie Cobian Backup verwendet um die erzeugten Datenbank Backup Dateien auf einen FTP Server zu sichern, hat man eine kostenlose Lösung zur Sicherung der SQL Datenbank.

Ich denke, ich werde bald man in einem neuen Beitrag beschreiben, wie man Dedizierte WEB Server, die man bei einem Hoster stehen hat, mit Hilfe von Batch Dateien und Cobian Backup WEB Seiten inkl. Datenbanken ganz einfach und kostenlos sichern kann.

SQL Express – Betriebssystemfehler 5

Ich hatte gerade mal wieder so eine „Erscheinung“ mit SQL Express.
Während der Entwicklung eines DotNetNuke Portals (Version 4.5.3) welches mit einer SQL Express Datenbank arbeitet, hatte ich, warum auch immer, die Datenbank mit dem SQL Server Management Studio angehängt (attached).


Ich konnte dann wunderbar meine Abfragen und Analysen mit dem Management Studio machen. Nachdem ich nun DotNetNuke aufgerufen habe, erhalte ich folgende Fehlermeldung:


Die physikalische Datei „C:\DNN_4_5_3\Website\App_Data\Database.mdf“ kann nicht geöffnet werden. Betriebssystemfehler 5: „5(Zugriff verweigert)“. Fehler beim Anfügen einer automatisch benannten Datenbank für die Datei C:\DNN_4_5_3\Website\App_Data\Database.mdf. Eine Datenbank mit diesem Namen ist bereits vorhanden, die angegebene Datei kann nicht geöffnet werden, oder sie befindet sich in der UNC-Freigabe.


Was war geschehen ?


SQLExpress hat als ich die Datenbank mit dem SQL Server Management Studio angehängt habe, doch tatsächlich die Dateiberechtigung der Datenbank geändert (es hat die nicht Standardberechtigungen einfach entfernt). Da aber damit DotNetNuke auf der Entwicklermaschine unter Windows XP den Maschinename\ASPNET Account verwendet um auf die Datenbank mit der User Instance zugreifen, muss dieser natürlich auch Zugriffsrechte auf die Datenbank haben (Das wird bei der Installation von DotNetNuke extra vergeben).


Nun gut, es ist sicherlich nicht so schlimm, aber im ersten Moment fehlt einem der Zusammenhang zwischen dem anhängen der Datenbank und dem Verlust von Dateirechten.

Microsoft SQL Server Management Studio Express

Alle, die neben der Leistungsfähigen Express Version des SQL Server 2005, auch das entsprechende Verwaltungstool zum verwalten von SQL Server 2005 Express Edition und SQL Server 2005 Express Edition with Advanced Services, benötigen, sollten sich das ebenfalls kostenlose SSMSE (Microsoft SQL Server Management Studio Express) von Microsoft besorgen.

Das Tool gibt es in einer 32 und einer 64 BIT Version.

SQL Express 2005 – Timeout

Nachdem immer wieder die Frage auftaucht, wie den die Timeout Einstellungen beim SQL 2005 Express voreingestellt sind und wie man diese anpassen kann, hier nun eine kurze Erläuterung:

Standard Timeout SQL 2005 Express

Der Default Timeout für Remoteabfragen beträgt 600 Sekunden.

Ändern des Timeout über SQL Server Management Studio (Express)

Zum Ändern des Timeout startet man die SQL Server Management Studio Konsole.

Meldet sich am Server (SQL 2005 Express) an

Positioniert die Maus über dem Server

Klickt mit der rechten Maus und Öffnet die Eigenschaften.

image

Nun selektieren Sie die Option  „Verbindungen“

clip_image001

Hier können Sie nun im Feld Timeout für Remoteabfragen den Timeout selbst einstellen.

 

Dann noch auf OK Klicken und fertig.