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:

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.

MySQL WordPress Datenbank Engine von InnoDB auf MyIsam ändern

Über das Thema welcher Tabellentyp (InnoDB oder MyIsam) für MySQL die bessere, schnellere oder robustere ist gibt es Unmengen an Diskussionen im Internet und ich möchte an dieser Stelle nicht damit weitermachen.
Vor allem nicht, da ich mich mehr im Umfeld von MS SQL Server bewege und MySQL nur hier und da verwende.

Im Zuge meiner Blogumstellung von dasBlog auf WordPress bin ich aber auf das Problem gestoßen, dass die von mir erstellte MySQL Datenbank für WordPress als Standard den Tabellentyp InnoDB verwendet hat, was für mich zuerst auch kein Problem dargestellt hat, sich aber im Laufe der weiteren Einrichtung von WordPress für mich doch als falsch herausgestellt hat. Eines der Plugins, welches Volltextsuche verwendet, setzt voraus dass die table_wp_posts als Tabellenformat das MyIsam Format verwendet.

Da ich in einer Datenbank nicht verschiedene Tabellenformate verwenden wollte, musste ich das Tabellenformat aller Tabellen ändern. Das hätte ich entweder für jede Tabelle manuell über phpMyAdmin machen können (was aber selbst bei nur 15 Tabellen) doch einige Zeit in Anspruch nimmt und vor allem wollte ich für spätere Tests eine schnelle Möglichkeit haben, den Tabellentyp sehr schnell von einem Format zu einem anderen zu ändern.

Das Resultat ist dieses nun folgende SQL Script was einfach über den phpMyAdmin ausgeführt werden kann.

alter table wp_blc_filters ENGINE=myisam;
alter table wp_blc_instances ENGINE=myisam;
alter table wp_blc_links ENGINE=myisam;
alter table wp_blc_synch ENGINE=myisam;
alter table wp_commentmeta ENGINE=myisam;
alter table wp_comments ENGINE=myisam;
alter table wp_links ENGINE=myisam;
alter table wp_options ENGINE=myisam;
alter table wp_postmeta ENGINE=myisam;
alter table wp_posts ENGINE=myisam;
alter table wp_terms ENGINE=myisam;
alter table wp_term_relationships ENGINE=myisam;
alter table wp_term_taxonomy ENGINE=myisam;
alter table wp_usermeta ENGINE=myisam;
alter table wp_users ENGINE=myisam;

Und wenn man die Engine von MyIsam nach InnoDB ändern möchte geht das natürlich auch.

alter table wp_blc_filters ENGINE=innodb;
alter table wp_blc_instances ENGINE=innodb;
alter table wp_blc_links ENGINE=innodb;
alter table wp_blc_synch ENGINE=innodb;
alter table wp_commentmeta ENGINE=innodb;
alter table wp_comments ENGINE=innodb;
alter table wp_links ENGINE=innodb;
alter table wp_options ENGINE=innodb;
alter table wp_postmeta ENGINE=innodb;
alter table wp_posts ENGINE=innodb;
alter table wp_terms ENGINE=innodb;
alter table wp_term_relationships ENGINE=innodb;
alter table wp_term_taxonomy ENGINE=innodb;
alter table wp_usermeta ENGINE=innodb;
alter table wp_users ENGINE=innodb;

MS SQL – Views ermitteln in welchen ein bestimmtes Feld verwendet wird

In einem recht umfangreichen Projekt (C# Windows Forms Anwendung) welches als Datenbank eine MS SQL Datenbank verwendet, musste ich Erweiterungen der Datenbank (zusätzliche Felder) vornehmen.

Da ich diese neuen Felder auch in allen vorhandenen Abfragen ergänzen musste, in welchen ein anders bereits vorhandenes Feld (wir nennen es einfach mal “EinfahrtLKW”) der gleichen Tabelle ausgegeben wird, habe ich nach einer Lösung gesucht um mir alle Abfragen (Views) anzeigen zu lassen, in dem das Feld EinfahrtLKW Verwendung findet.

Um dies zu realisieren habe ich folgende Systemsicht verwendet:

INFORMATION_SCHEMA.VIEW_COLUMN_USAGE

Meine Abfrage sieht dann so aus:

select * from INFORMATION_SCHEMA.VIEW_COLUMN_USAGE where COLUMN_NAME = 'EinfahrtLKW'

Und das Ergebnis sieht dann so aus:

 image

Mit dieser Information habe ich nun die Name der Views, die ich anpassen muss.

Microsoft SQL Server Management Studio – Spaltenüberschriften fehlen beim kopieren der Abfrageergebnisse

Wer kennt das nicht, mal schnell eine Abfrage auf eine SQL Datenbank mit dem Microsoft SQL Server Management Studio gemacht, Ergebnis der Abfrage markiert und dann mit Copy / Paste das Abfrageergebnis einfach in Excel eingefügt.

Soweit geht das auch ohne Probleme. Störend dabei ist nur, dass die Spaltenüberschriften (Spaltenheader) nicht mit kopiert werden und man diese wenn man sie benötigt manuell übertragen muss.

Wenn man das Ergebnis mit Copy / Paste als Text in einen Texteditor einfügt, sind die Spaltenheader übrigens vorhanden.

Das kann aber auch in Excel so sein.

Das Microsoft SQL Server Management Studio besitzt einen Optionsschalter mit dem man dieses Verhalten steuern kann.

Der Optionsschalter befindet sich wie nachfolgend dargestellt unter Extras –> Optionen

image

Man muss einfach nur das Häkchen bei der Option:

Spaltenheader beim kopieren oder Speichern der Ergebnisse einschließen.

setzen und schon wird auch der Spaltenheader kopiert.

Übrigens kann man das Verhalten beim einfügen in einen Texteditor genau so steuern, nur da ist die Default Einstellung eben; das Häkchen ist gesetzt (siehe Abbildung).

image

T-SQL – Select * from < table > where < datetimeField > < 2007

Da mein Hauptgeschäft nicht in der Erstellung von SQL Abfragen liegt, kommt es immer wieder vor, dass ich nach ein und der gleichen Lösung für ein Problem immer wieder mal recherchieren muss, da ich mir die Lösungen nicht (bzw. nicht immer) merken kann.

Dieser Beitrag fällt unter diese Kategorie (Und nachdem ich es nun aufgeschrieben habe, werde ich es wohl nie mehr vergessen smile_shades, na dann hätte es ja was genutzt dies hier aufzuschreiben.).

Nun aber zum eigentlichen Problem bzw. zur Lösung:

Ich weiß nicht wie oft ich schon mal schnell eine SQL Abfrage machen musste, die alle Daten anzeigt, oder löscht oder was auch sonst immer, welches entweder vor, nach oder in einem bestimmten Jahr einen Eintrag in einem datetime Feld enthält

Bei eigenen Tabellen Entwürfen häufig das Feld „Created“, oder „LastChange“ – ein Datenbank Feld mit dem Datentyp datetime.

Nun ist die Abfrage „Select * from  <table> where <datetimeField>  < 2007“ thumbs_down wie in der Überschrift verwendet syntaktisch nicht falsch, also es wird kein SQL Fehler erzeugt, aber es wird auch nicht das gewünschte Ergebnis angezeigt.

So wie die Abfrage aufgebaut ist, wird das Ergebnis leer sein, da keiner der datetime Werte kleiner sein dürfte als der Wert 2007.

Die korrekte Abfrage (besser gesagt, eine korrekte Möglichkeit) dafür sieht wie folgt aus:

Select * from  <table> where DatePart(year,<datetimeField>)  <= 2007 thumbs_up

Hier wird nun nur nach dem Jahr innerhalb des datetime Ausdrucks verglichen und der Vergleich mit 2007 ist dann richtig.

Mehr über DatePart auf MS TechNet

SQL Profis mögen mir verzeihen wenn ich bei den verwendeten Begriffen nicht immer ganz getroffen habe, aber wie gesagt, SQL Abfragen ist nicht unbedingt mein Spezialgebiet. T-SQL – Select * from < table > where < datetimeField > < 2007 weiterlesen

SQL 2005 Express Edition – Beschränkungen

Immer wieder taucht die Frage auf, welchen Beschränkungen die Express Edition des SQL 2005 Server aus dem Hause Microsoft unterliegen.

Vorab gesagt: Es sind weniger Beschränkungen als es der Vorgänger die MSDE hatte.
Und vor allem wird die Express Edition nicht auf eine Anzahl gleichzeitiger Threads beschränkt wie das bei der MSDE der Fall war.

Übrigens, wenn ich hier von der Express Edition spreche, dann ist dies nicht ganz korrekt, da es zwei Versionen gibt.

Aber nun zu den Beschränkungen:

  • Anzahl unterstützter CPU’s = 1
  • Maximale Speichernutzung (RAM) des SQL Server’s = 1 GB
  • Keine direkte 64 BIT Betriebssystem Unterstützung (nur über WOW)
  • Maximale Datenbankgröße (ohne Log File) = 4GB
  • Mergereplikation und Transaktionsreplikation = nur Abonnenten
  • Volltextsuche (nur in der Express Edition with Advanced Services)

Einen kompletten Vergleich der einzelnen Editionen findet man wenn man dem nachfolgenden Link folgt:

http://www.microsoft.com/germany/sql/editionen/default.mspx

SQL Server 2005 Express Editionen

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.