Schlagwort: SQL

TFS-Reports und die Date/Time Picker mit den regionalen Einstellungen für Deutschland…

Wer Reports aus dem TFS in Visual Studio benutzt kann oft genug nicht die Date/Time Picker verwenden, wenn er die deutschen  regionalen Einstellungen verwendet.

Wenn man einen dieser Date/Time Picker benutzt wird das Datum im englischen Format in das Eingabefeld übernommen, was dann anschließend mit der Meldung

Der Wert, der für den ParamEndDate-Berichtsparameter angegeben ist, ist für dessen Typ ungültig. (rsReportParameterTypeMismatch)

quittiert wird.

Das ganze ist kein Problem des TFS sondern des MS-SQL 2005 Reportservers.
Es gibt für den MS-SQL 2005 SP2 einen nicht offiziellen Hotfix, der dies behebt:
http://support.microsoft.com/kb/949095/en-us

Leider muss man um ihn zu erhalten den Microsoft Support kontaktieren. Einfach dort den Hotfix anfordern. Mir ist nicht klar warum man diesen Hotfix nicht direkt herunterladen kann.

Weitere Infos auch hier:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=271928

Alle reden von Sichertheit in der IT-Branche… Alle?

Bei einem Kunden muss ich aktuell einem Problem auf den Grund gehen, das irgendwie mit Locks in den tiefsten Tiefen des SQL-Server 2005 zu tun hat. Aus diesem Grund habe ich Einblick in den originalen – doch etwas größeren – Datenbestand erhalten. Besagter Kunde ist in seiner Branche ziemlich populär. Es werden in dieser Datenbank 750.000 Kunden verwaltet. Alles aktive Kunden eines bestimmten Produkts einer kleinen geographischen Zone in Deutschland. Qualitativ wirklich aktuelles Material, denn alle diese Datensätze sind wirklich aktive Kunden, d.h. bekommen mindestens einmal im Jahr eine Rechnung.

Um sich nun mit unserer Anwendung als Benutzer Administrator anzumelden benötigte ich noch ein Kennwort. Das hatte mir keiner mitgeteilt (bis jetzt). Aber was soll’s, probieren wir doch mal 😉

  1. Versuch: Der Firmenname
  2. Versuch: Der Produktname
  3. Versuch: admin… Bingo 😮

Ich will nicht davon reden, wieviele Aktivität betrieben wird,  die Datenbanken nach außen abzuschirmen. Auch will ich nicht über die interne Panik klagen, die uns gegenüber immer geschoben wird, dass alles hoch sicher und geheim zu behandeln ist.

Jeder Angestellte, mit etwas Spielwitz kann in etwa 20 Sekunden als Admin an alle Daten…

Nur als Anmerkung: Dieses Sicherheits-Problem ist natürlich mittlerweile behoben… :mrgreen:

MS-SQL abfragen ob es noch genug Plattenplatz gibt (Teil 2)

Es gibt noch ein paar nette Tabellen und Abfragen die einem Informationen über die physikalische Größe eine SQL-Datenbank liefern. Denn sowohl die Daten-Datei als auch die Protokolldatei können über nicht allokierten Speicherbereich verfügen. Wenn man also wissen will, wie viel Platz wirklich noch verfügbar ist, muss auch dieser noch verfügbare Platz mit einbezogen werden.

Es sind also noch zu ergänzen:

  1. Sehr einfach ist die dbo.sysfiles zu verwenden. Auch über diese Tabelle erhält man schnell die Größe der Protokoll- und Datendatei in 8kb Blöcken.
  2. sp_spaceused liefert einem die komplette Größe der Datendatei und die Größe des nicht verwendeten Bereiches. sp_spaceused liefert übrigends zwei Resultsets wenn man es ohne Objektnamen aufruft! Nicht wundern.
  3. Und last but not least DBCC SQLPERF(LOGSPACE), dass die selbe Information für die Protokolldatei liefert. D.h. Größe der Protokolldatei in MB und den prozentual benutzten Speicherbereich. 

PS: Wie man so etwas herausbekommt. ❓
Nun man kann die MSDN lesen, aber man kann es sich auch einfacher machen. 😉
Ich habe einfach den SQL Profiler angeworfen, dann den SQL Server Enterprise Manager gestartet. Im Enterprise Manager habe ich die Taskpad Ansicht gewählt und einfach mal F5 gedrückt. Der Profiler hat mir dann gezeigt was der Enterprise Mangager so abfragt um die relevanten Daten zu ermitteln.

MS-SQL abfragen ob es noch genug Plattenplatz gibt

Kann man den MS-SQL Server abfragen ob es noch genug Plattenplatz gibt?

Manche Operationen kosten sehr viel Platz, besonders wenn man Datenbanken umstrukturiert. Da kann es leicht sein, dass gleich 100% mehr Platz benötigt wird. Zum einen weil die Protokolldatei evtl. immens wächst und zum zweiten weil einfach die Tabellen stark anwachsen weil zum Beispiel neue Indexe hinzukommen oder Spalten auf Unicode umgestellt werden.

Kann man also irgendwie den freien, zur Verfügung stehenden Platz ermitteln und entsprechende Berechnungen anstellen?

Ja! Es geht.

  1. Ausgangspunkt ist hier zum einen die dokumentierte System Tabelle sysdatabases, die den Namen der Datenbank, und den Namen physikalischen mdf-Datei liefert.
  2. Nun benötigen wie noch die aktuelle Größe, die wir ohne Probleme mit der Storedprocedure sp_databases ermitteln können, die Namen, die Größe in KB und eine NULL Spalte zu dieser Datenbank liefert.
  3. Den dritten und letzten Baustein für die Aufgabe liefert die nicht dokumentierte Funktion master..xp_fixeddrives, die in der ersten Spalte den Laufwerkbuchstaben liefert und in der zweiten den freien Speicherplatz in MB.

Wie man jetzt errechnet ob eine Größenänderung um 75% noch abgedeckt wird, bleibt dem Leser überlassen. Nett nicht! 🙂

❗ BTW: Diese Funktionen laufen verifiziert auf MS-SQL 2000 und auch auf MS-SQL 2005 Servern inkl. der Express-Edition.

Link Useful undocumented extended stored procedures

UPDATE Statement für die Tabelle Upgrade eines MSI-Projektes

Ich habe gerade Stunden verbracht ein VBS-Skript zu schreiben, dass ein Microsoft Installer Projekt anpasst. Aufgabe war einige bestehende Einträge in der Tabelle Upgrade zu ändern. Es sollten nur die Wert in den Spalten VersionMin und VersionMax angepasst werden.

Ein schönes UPDATE-Statement war schnell erzeugt. Aber es schlug immer fehl mit:
PostBuild.vbs(28, 1) Msi API Error: OpenView,Sql  😕

Nach längerem Nachdenken, Suchen und Analyse mit Orca, stellte ich fest, dass die Spalten UpgradeCode, VersionMin, VersionMax, Language, Attributes alle den Primary-Key bilden.

Nun wird sich mancher Fragen: Na und?!?!

Nun die MSI Dokumentation sagt zu UPDATE-Statements in MSI Dateien:
❗ UPDATE queries only work on nonprimary key columns!

Also doch alle Records einlesen, löschen und neu schreiben…