Glorf IT

Im Dr. Web Weblog wurde vor einiger Zeit mal der Data Generator beschrieben. Damit kann man sich für einzelne Tabellen Testdaten generieren lassen. Das funktionierte schon ganz gut, verschiedene "Typen" sind möglich. Im Typ "Mailadresse" kam bei meinem Test aber ein Semikolon vor.

Das erinnert mich daran, dass ich mich am liebsten sofort mit den Unit-Test für Stored-Procedures beschäftigen würde, die im Rahmen der "Visual Studio 2005 Team Edition for Database Professionals" angeboten werden. Für diese Tests bietet das Werkzeug ebenfalls eine automatische Test-Daten-Generierung an. Einfach traumhaft.

Details werden im Abschnitt "Data Generation" des Artikels "What Microsoft Visual Studio 2005 Team Edition for Database Professionals Can Do for You" beschrieben.

Im gestrigen Posting zu SQL habe ich noch einen anderen Trick von Itzik Ben-Gan verwendet, mit dem man besonders effizient Daten generieren und in eine Tabelle schreiben kann: beim Füllen der Hilfstabelle, in der z.B. die Zahlen von 1 bis 8000 gespeichert werden und daher nur eine Spalte "n" hat.

Prozedural würde man eine Schleife von 1 bis 8000 machen und 8000 Insert-Befehle absetzen. Das ist allerdings im mengenorientirten SQL sehr ungünstig, weil die vielen Einzeloperationen unnötig viel Zeit kosten. Den Unterschied bemerkt man vor allem, wenn es anstelle der 8.000 mal 8.000.000 Datensätze sind…

Viel effizienter ist es einen Datensatz einzufügen und dann in einer Schleife die Daten immer wieder zu kopieren (und damit zu verdoppeln). Für 8.000 Datensätze sind dann gerade mal 13 Inserts notwendig. Aber erst mit 80.000 bzw. 800.000 Datensätzen wird die Performance "spürbar". Im Vergleich zur "normalen" Schleife ergibt sich auf meinen heimischen PC ein Performance-Unterschied von Faktor 3 bis 6.

declare @max integer,
@rc integer;

while @rc<=@max begin -- sehr effizentes Füllen durch mengenorientierten Ansatz: insert into hilfstabelle (n) select @rc+n from hilfstabelle where @rc+n<=@max; set @rc=@rc*2; end

Damit nicht ungewollt zu viele Datensätze eingefügt werden, ist der Filter "where @rc+n<=@max" im SELECT des Inserts notwendig. Vorbereitung: if object_id(N'hilfstabelle') is not null drop table hilfstabelle
create table hilfstabelle (n integer primary key)

Der Code steht auch zum Download bereit.

Gestern kam mein Kollege Alexander mit einer ganz spannenden SQL-Fragestellung zu mir. weil die Anwendung auch noch den SQL-Server-2000 unterstützt, mussten wir etwas in die Trickkiste greifen. Ich habe die Fragestellung jetzt daheim noch mal unter dem SQL-Server-2005 nachvollzogen und konnte dabei ein paar der schicken, neuen Features nutzen…

Die Frage ist, wie man Strings, die über eine Legacy-Schnittstelle kommen und so in die Datenbank geschrieben wurden, aufteilen kann. Beispielsweise soll die Zeichenfolge "1234#12#bla#blub#132" mit SQL anhand des Trenners "#" in die Einzelbestandteile aufgeteilt und dann weiterverarbeitet werden.

So könnte die Tabelle aussehen:

Eine Lösung, die mir persönlich besonders gut gefällt, hat sich der große Itzik Ben Gan ausgedacht: Dabei wird eine Hilfstabelle benötigt, die nur eine Spalte hat, und für jede Zahl einen Datensatz enthält.

Dann kann man mit einem Cross-Join zwischen den Tabellen in der Where-Klausel diejenigen Sätze rausfischen, die an der n-ten Position ein "#" haben:

...
from LegacyInput
cross join hilfstabelle
where substring('#'+Zeichenkette+'#', n, 1)='#'
and n <= len(Zeichenkette)+2

Damit das erste Teilstück bei 1 anfängt, wird noch ein "#" vor den Anfang angefügt. Außerdem müssen nur die Datensätze untersucht werden, die kleiner/gleich der Länge der Zeichenkette sind. Das ist eigentlich doppelt gemoppelt und kann daher auch entfallen.

Im SELECT werden dann die Einzelbestandteile rausgelöst: von n bis zum nächsten "#", wobei "n" eine Position ist, an der der ein "#" gefunden wurde.

substring('#'+Zeichenkette, n+1, charindex('#',Zeichenkette+'#',n)-n)

Das gesamte Statement sieht dann so aus:

select lfdNr,
n-len(replace(substring('#'+Zeichenkette, 1, n), '#', '')) as "TeilNr",
substring('#'+Zeichenkette, n+1, charindex('#',Zeichenkette+'#',n)-n) as "Teilstück",
Zeichenkette
from LegacyInput
cross join hilfstabelle
where substring('#'+Zeichenkette, n, 1)='#'
and n <= len(Zeichenkette)+1

Und so das Ergebnis:

Das ist aus Datenbanksicht, aber nicht optimal. Wünschenswert wäre ein pivotiertes Ergebnis:

Das kann man dann ganz einfach mit dem PIVOT-Konstrukt erreichen:

SELECT *
FROM (select
LfdNr,
'attr'+convert(varchar,n-len(replace(substring('#'+Zeichenkette, 1, n), '#', ''))) as "Attribute",
substring('#'+Zeichenkette, n+1, charindex('#',Zeichenkette+'#',n)-n) as "Teilstück"
from LegacyInput
cross join hilfstabelle
where substring('#'+Zeichenkette, n, 1)='#'
and n <= len(Zeichenkette)+1 ) AS ATR PIVOT ( MAX("Teilstück") FOR attribute IN([attr1], [attr2], [attr3], [attr4], [attr5], [attr6], [attr7], [attr8], [attr9], [attr10]) ) AS PVT

Das komplette Beispiel steht auch zum Download bereit.

Gestern fragte mich ein Kollege, wie man bestimmte Informationen in das Ereignisprotokoll des Windows-Server auf dem der SQL-Server läuft protokollieren kann. Dazu gibt es zwei Möglichkeiten, die beide sowohl mit Version 2000 und Version 2005 funktionieren.

Fehler werfen

Man kann einen Fehler "with log" werfen. Der Fehler wird an den Client geschickt und in der Ereignisanzeige protokolliert. Je nach Severity wird ein Fehler, Warnung oder Information geworfen. Das dürfen übrigens nur SysAdmins.

raiserror ('Dieser Text soll im Eventlog stehen (als Information)', 1,1) with log
raiserror ('Dieser Text soll im Eventlog stehen (als Warning)', 15,1) with log
raiserror ('Dieser Text soll im Eventlog stehen (als Fehler)', 16,1) with log


Meldung nur in Ereignisanzeige schreiben

Man kann die Meldung mit xp_logevent aber auch einfach nur wegloggen, ohne einen Fehler an den Client zu schicken. Das dürfen auch nur SysAdmins.

EXEC master.dbo.xp_logevent 60000, 'Dieser Text soll im Eventlog stehen (als Info)', informational
EXEC master.dbo.xp_logevent 60000, 'Dieser Text soll im Eventlog stehen (als Warning)', warning
EXEC master.dbo.xp_logevent 60000, 'Dieser Text soll im Eventlog stehen (als Fehler)', error

Zur Kontrolle muss man jetzt ins Eventlog schauen. Die XP xp_eventlog zum Lesen aus der Ereignisanzeige gibt es ja leider nicht mehr… schnüff

Im Artikel "Fixing damaged pages using page restore or manual inserts" beschreibt Paul Randal ganz trickreich, wie man den Inhalt einzelner Seiten aus der Sicherung holt. Das ist in der Praxis durchaus relevant, wenn nur wenige Datenbank-Seiten korrupt wurden. Das war mit den bisherigen SQL-Server-Versionen nicht möglich, bzw. es war viel Handarbeit gefragt.

Am SQL-Server-2005 geht es etwa so:

RESTORE DATABASE dbccpagetest PAGE = '1:158' FROM DISK = 'C:\dbccpagetest.bak';

Dazu fragt Paul:

Isn't that cool? You can restore up to 1000 single pages from a backup at a time.

Und meine Antwort lautet: JAAAAAAA!!!

Es gibt auch eine Schattenseite: es geht nicht immer. Es geht nur, wenn entweder die Seite seit dem Backup nicht "verschoben" wurde, die Daten nicht geändert wurden oder die Datenbank im Recovery-Modus "Full" bzw. "Bulk" war:

You can use single-page restore if you're on SQL Server 2005 and the database is in Full or Bulk-Logged recovery mode, otherwise you need to use the manual method, and that will only work as long as you know the data being salvaged hasn't changed since the last backup.

Ok, die manuelle Methode ist auch nicht von schlechten Eltern. Darauf bin ich leider nicht selber gekommen, obwohl sie auf der Hand liegt. Das liegt aber vermutlich daran, dass bis zu mir meist nur die Fälle vordringen, die keine funktionstüchtige Datensicherung haben.

Hier steht es komplett, vom großen Paul Randal Himself.

Im Artikel "Running a master db residing stored procedure in current database context" beschreibt Mladen Prajdicand, wie man aus einer normalen Prozedur in der Master-Datenbank eine System-Prozedur machen kann. Das hat den Vorteil, dass sie aus jedem Datenbank-Kontext aus aufgerufen werden kann. Sie liest dabei immer die Informationen aus den Verwaltungstabellen der jeweiligen Datenbank. Er beschreibt dazu zwei Voraussetzungen, die am SQL Server 2005 notwendig sind:

• Die Prozedur beginnt mit "sp_" und
• sie wurde als Systemprozedur gekennzeichnet.

Letzteres geht am SQL-Server-2005 mit "EXEC sp_MS_marksystemobject ", ist aber nicht immer unbedingt notwendig, dazu später mehr. Ich gebe zunächst mal ein Beispiel, damit klar wird, was gemeint ist:

Wenn man zwei Tabellen gleichnamige anlegt, eine in der einen Datenbank, die andere in einer anderen, z.B. eine in der Master und die andere in der Nordwind, dann kann man beide Tabellen mit der gleichen Prozedur abfragen.

-- Tabelle YouAreIn in Master anlegen und mit "Master" füllen
create table master.dbo.YouAreIn (dbname sysname not null);
insert into master.dbo.YouAreIn (dbname) values ('Master');

– Tabelle YouAreIn in Nordwind anlegen und mit "Northwind" füllen
create table Northwind.dbo.YouAreIn (dbname sysname not null);
insert into Northwind.dbo.YouAreIn (dbname) values ('Northwind');
go
use master
go
create procedure dbo.sp_where_am_i
as
select dbname
from YouAreIn – hier keine Datenbank angeben
go
– Als Systemprozedur markieren
EXEC sp_MS_marksystemobject 'sp_where_am_i'

Jetzt kann man in unterschiedlichen Datenbank-Kontexten die Prozedure aufrufen und es wird automatisch die "richtige" Tabelle gelesen:

use master
exec sp_where_am_i

Das liefert als Ergebnis "Master". Während das untige Statement "Northwind" meldet:

use Northwind
exec sp_where_am_i

Spaßigerweise haben die Systemprozeduren noch einen Insider-Hack: Wenn man den Datenbanknamen vor die Systemprozedur stellt, dann wird sie in dem Kontext ausgeführt:

use master
exec Northwind..sp_where_am_i

Das liefert "Northwind"!

Keine Regel ohne Ausnahme…

Um abwärtskompatibel zu sein, gibt es auch hier eine Ausnahme… Auch ohne das Markieren als systemprozedur wird die Prozedur im Kontext der Datenbank ausgeführt. Die Bindung zu den Tabellen bleibt aber zu den Tabellen in der Master bestehen.

Beispielsweise liefert die folgende Prozedur (in der Master angelegt, nicht als Systemprozedur gekennzeichnet) immer den "richtigen" Datenbank-Kontext und immer den Inhalt der Tabelle aus der Master.

create procedure sp_where_am_i_zwei
as
select db_name() as [DB-Kontext],
dbname as [Tabelle-Aus]
from YouAreIn

Aber es gibt noch eine weitere Ausnahme: Wenn man lediglich vor hat aus den "alten" Systemtabelle, wie sysobjects, zu lesen, dann verhält sich die Prozedur, wie ganz oben beschrieben. Wenn man aber aus den "Neuen" liest, wie bspw. "sys.objects", dann muss sie "markiert" werden, um das Ziel zu erreichen….

Ein Tipp an alle, die mit der "Visual Studio Team Edition for Database Professionals" arbeiten wollen: Wenn man ein Datenbank-Projekt anlegt, dann versucht das Studio sich mit dem SQL-Server zu verbinden, den man für die "design-time validation" angegeben hat.

Das wird benötigt, um für Stored-Procedure, Functions, Views, usw. eine Syntax-Überprüfung durchführen zu können, ohne dass die dazugehörige Datenbank überhaupt schon angelegt wurde. Man kann sein Projekt komplett "offline" entwickeln, die Syntax wird währenddessen überprüft, und die Datenbank erst ganz zum Schluss zusammenbauen lassen. Echt schick.

Laut Doku muss es sich bei diesem Server um eine "SQL Server 2005 Developer Edition" handeln. Um sie nachträglich zu ändern, muss man keine Projekt-Einstellung suchen. Es handelt sich dabei um eine Einstellung des Visual-Studio. Man findet sie unter "Options | Database Tools | design-time validation database"

Die beliebte SQL-Wunschliste gibt es ja leider schon lange nicht nicht mehr. Ein paar Hintergründe dazu beschreibt Euan Garden in seinem Blogbeitrag "Farewell SQLWISH": Ich verstehe es so, dass einfach zu viele Mails kamen. Deswegen wurde ein richtiges "System" eingeführt. Naja, dass Feedback bei SQLWish war jetzt auch nicht so, dass ich den Eindruck hatte, man wartet nur auf meinen Wunsch. Eigentlich wollen Entwickler ja auch entwickeln. Klar freue ich mich über Feedback zu unserem Produkt, aber wenn ich 500 "Wünsche" auf mein Team verteilen müsste, dann hätte ich auch bald die Nase voll…
😉

Die Nachfolgelösung "Productfeedback" schien sich nicht so richtig bewährt zu haben, denn Brian Moran machte am Wochenende darauf aufmerksam, dass man jetzt bei Connect-Microsoft unter "Anregungen zum SQL Server" seine Anregungen zum SQL-Server platzieren kann.
Meine These: Jetzt werden die Wünsche einfach durch Support-Mitarbeiter vorsortiert und müssen nicht auch noch von den Entwicklern durchgesehen werden, die ja eigentlich war anderes zu tun haben. Wenn ich richtig liege, dann werden sie nach Themen zusammengefasst und je nach Anzahl der Eingang zu einem Thema "bewertet".

Ich werde diese Möglichkeit demnächst mal ausprobieren…

Neulich habe ich über den Money-CNN-Artikel berichtet, der sich genüsslich darüber auslässt, dass Microsoft von IBM vorgeführt wird: Deren Datenbanksystem DB/2 läuft bereits unter Vista, während Microsoft für seinen SQL-Server noch auf das SP2 warten muss.

Mein Kollege Günther machte mich auf die Reaktion von Mike Wachal aus dem SQL-Express-Team in seinem Weblog aufmerksam. In dem Artikel "Inaccuracies in recent CNNMoney.com article about SQL Express and Windows Vista" bringt er seinen Ärger zum Ausdruck, dass SQL-Express sehr wohl schon laufe, aber bestimmte Funktionen eben noch nicht ganz. Er schreibt unter anderem:

It is true that there is a known issue related to how Vista User Account Control impacts the ability to connect to a default installation of SQL Express SP1, but I've documented the way to work around that problem in here. (For most deployed application this issue will not be a problem as they already create explicit Logins to access the database rather than rely on the default Logins. See the post for more information.) I've also discussed how the installation process in SQL Express SP2 has been modified to help manage UAC in this post.

Das ist interessant, weil ich auf offizielle Wege nicht so detaillierte Infos bekommen konnte, was denn nun nicht geht. Für die MSDE (SQL Server 2000) schon gleich dreimal nicht. Die lief ja wenigstens noch auf den Beta-Versionen von Vista. Mit der Freigabeversion ist aber deren Installation nicht mehr möglich. Schade.

Spannend sind seine Aussagen im nächsten Absatz:

SQL Express SP1 will run on Windows Vista.

Microsoft supports customers running SQL Express SP1 on Windows Vista.

Das habe ich von offizieller Seite aber gaaanz anders verstanden. Möglicherweise haben das die normalen Microsoft-Mitarbeiter auch nicht so interpretiert. Das geht auch anderen so: Der IBM-Mitarbeiter Leon Katsnelson (verantwortlich für DB2 Express) ließ es sich auch nicht nehmen dazu seinen Senf als Kommentar zu geben. Einfach spitze!

Gestern Nacht wurde die SQL Server 2005 Compact Edition freigegeben. Es folgenden die typischen Einsatzgebiete aus Sicht von Microsoft, aber ich behaupte mal, dass sich die Edition für andere Zwecke durchsetzen wird:

* Portable enterprise applications
* Occasionally-connected & offline use
* Embedded in applications & devices

Sie hat ein paar echt charmante Vorteile:

• Einfache Installation mittels, oder einfach nur DLLS kopieren
• Für Installation kein Admin notwendig
• Läuft auf nahezu allem das mit Windows anfängt (alles was seit inkl. 2000 freigegeben wurde)
• Es werden bis zu 256 gleichzeitige lokale Verbindungen unterstützt.
• Datenbanken können auf einer Freigabe gespeichert werden.
• Die Datenbank-Datei kann mit einem Passwort vor Zugriff geschützt werden.
• Die Datei-Datei kann verschlüsselt werden.
• Und es kann völlig kostenlos verteilt werden!

Aber auch Schattenseiten:

• Keine native 64-Bit-Unterstützung. Ist für nächste Version angekündigt.
• maximal 4GBytes große Datenbanken möglich
• keine Netzwerkunterstützung
• keine prozeduralen Sprachelemente (IF, Case, WHILE, …)
• keine Stored-Procedures, keine Functions, keine Trigger, keine Views
• kein XML, kein XPATH, kein XQUERY
• kein .Net

Mein Resümee: klein, aber fein. Kein Generalist, aber für kleine Anwendungen ohne aufwändige Installation gut geeignet.

Anbei ein paar weiterführende Links:

• SQL Server Compact Edition Overview (Doc)
• SQL Server Compact Edition Datasheet (Doc)
• Comparing SQL Server Compact and SQL Server Express (Doc) – besonders gut finde ich die Vergleichstabelle auf Seite 8.
• SQL Server Compact Edition Forum

Weitere Downloads zu dem Thema:

• Microsoft SQL Server 2005 Compact Edition Server Tools
• Microsoft SQL Server 2005 Compact Edition Tools of VS 2005 SP1
• Microsoft SQL Server 2005 Compact Edition Developer SDK

Heute habe ich mir mal angesehen, wie man im "SQL Server Management Studio" (SSMS) beim Dialog zum "Datei öffnen" die Icon-Bar auf der linken Seite mit seinen eigenen Lieblingslinks "enhancen" kann: Neben dem "Desktop" und "MyProjects" beispielsweise noch "Schulungen" und "Skript-Pool" (siehe Bild).
Ich fand leider noch keine Möglichkeit das mittels eines Optionsdialogs zu tun, aber mein Freund RegMon konnte helfen.

Aber man kann sich recht einfach eine REG-Datei erstellen und darin die eigenen Vorstellungen umsetzen. Hier ein Beispiel, um obiges Ergebnis zu erreichen:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server\90\Tools\Shell\Open Find\Places\UserDefinedPlaces\Places2]
"Name"="Skript-Pool"
"SortAscending"=dword:00000001
"Path"="E:\\MyProjects\\SQL-Scripts"

Anleitung: obigen Inhalt in eine Text-Datei schreiben, den eigenen Wünschen anpassen, speichern. Die Datei in "irgendwas.REG" umbenennen und Kontextmenü "Zusammenführen" ausführen.
Falls es nicht klappt, könnte das daran liegen, dass von Ihrem Browser die geraden doppelten Anführungszeichen nicht richtig dargestellt wurden und beim Copy&Paste falsch rüber kamen. In diesem Fall bitte die Beispiel-Datei speichern und verwenden.

Wenn man das hinterher mittels RegEdit ändern oder löschen will, dann ist eine Sicherung der Registry Pflicht! An dieser Stelle muss ich einfach einen Hinweis auf meinen Kollegen geben, der bei geöffnetem RegEdit mit seiner Orange herumspielte. Plötzlich entglitt sie ihm und rollte so unglücklich von links oben nach rechts unten über die Tastatur, dass sie zuerst über DEL und später auch über J und SPACE rollte. Aus Gründen des Anstands nenne ich keinen Namen.
Danach war die Registry sehr aufgeräumt.

Update: Mein Kollege wies mich darauf hin, dass ich den Sachverhalt völlig falsch dargestellt habe. Es handelte sich in Wirklichkeit um einen großen Pfirsich. Er vermutet, dass eine Orange gar nicht die nötige Masse aufgebracht hätte, um so viel Schwung zu bekommen, möchte seine These aber nicht austesten…
🙂

Wenn man wirklich will, hier noch ein Hinweis: Nach dem ersten Aufruf verschwindet der Wert "Path" und wird durch "Pidl" ersetzt. Will man den Pfad nachträglich ändern, dann muss man "Pidl" löschen und einen neuem "Path" eintragen. Wenn man neben den Einträgen "Name", "Path", etc, weitere benötigt, dann kann man sich an den Tipps im Dokument zu Office orientieren.

Standard-Dialoge der anderen Anwendungen

Wenn man hingegen die Standard-Dialoge der anderen Programme verändern will, dann geht das (etwas eingeschränkt) mit dem Common dialog im "TeawkUI für XP" (aus den PowerToys). Wer selbst Hand anlegen will, kann sich ja mal den Registry-Key
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\comdlg32\PlacesBar ansehen.

Wenn man den Dialog in Microsoft Office verändern will, dann findet man bei Microsoft im Artikel "How to customize the My Places bar in both the Open and the Save As dialog boxes in Office" Rat.

Wie es beim Visual-Studio geht, schreibe ich morgen. Ich muss jetzt los…

Anbei ein Tipp von meinem Kollegen Vladimir: Wenn man seine Datenbankan auf FAT32-Partitionen speichert, dann ist bei 4 GByte Schluss mit lustig. Dann kommt beim Einfügen weiterer Datensätze die Meldung:
Could not allocate space for object 'MyTab' in database 'MyDB' because the 'PRIMARY' filegroup is full.

Weitere Hinweise dazu stehen im MS-Artikel "Limitations of the FAT32 File System in Windows XP" (auch auf deutsch erhältlich).

Es gibt zwei Arten von Abhilfe:

• Das Dateisystem von FAT32 nach NTFS umwandeln oder
• die Daten auf mehrere Datenbank-Dateien verteilen.

Für FAT lag die Grenze bekanntlich bei 2 GBytes, NFTS hat derzeit keine praktisch relevante Grenze. So große Platten gibt es noch lange nicht…
😉