mssql

Was ich von dieser Mitteilung im Microsoft SQLNCli Team Blog halten soll, weiß ich noch nicht so ganz: Microsoft is Aligning with ODBC for Native Relational Data Access.

Demnach wird der SQL Server „Denali“ die letzte Version sein, die den Zugriff auf die relationale Datenbank über den OleDB Provider für SQL Server unterstützt; nach Ende des Lifecycles von Denali gilt OleDB für SQL Server dann als abgekündigt. Zukünftig würde dann nur noch ODBC weiterentwickelt, mit dem Hinweis darauf, das diese API für allen Plattformen verfügbar sein und man somit nur noch eine einheitliche API hätte.

Wohlgemerkt, das gilt nur für OleDB für den SQL Server Provider, für Analysis Services OleDB oder gar OleDB Provider von anderen Herstellern gilt das nicht. Auch der Ado.Net SQLClient wird weiterentwickelt und ist ebenfalls nicht betroffen.

Im SQL Server Data Access Forum gibt einen gleichnamigen Thread „Microsoft is Aligning with ODBC for Native Relational Data Access“ aus MSFT Reihen, der ein klein wenig detaillierter ist und eine kleine FAQ darstellen soll. Wie es aber konkret weitergehen und welche nächsten Schritte es geben wird, ist dem auch nicht zu entnehmen. Nur mal als Beispiel SSIS Pakete, hier stehen neben Ado.Net bisher nur OleDB Provider zur Verfügung, ODBC kann man bisher nicht verwenden. Das würde bedeuten, man darf (mal wieder) alle SSIS Pakete, die auf eine SQL Server zugreifen, auf ODBC umbauen.

In der Data Access Technologies Road Map (aus Januar 2002, aber mit Update im Juni 2011) kann man hingegen unter „Deprecated MDAC/WDAC Components“ nur erfahren, das der alte „Microsoft OLE DB Provider for SQL Server (SQLOLEDB)“ Treiber aus dem MDAC abgekündigt ist und nicht mehr verwendet werden sollte; für Neuentwicklung wird hier noch der „SQL Server Native Client OLEDB Provider“ empfohlen.

Nun ja, zum Glück wird nichts so heiß gegessen, wie es gekocht wird und es dauert auch noch etwas, bis Denali erscheint und dann seine 7 Jahre auf dem Buckel hat, bis diese Version aus dem Lifecycle läuft. Bis dahin wird sich mit Sicherheit noch das eine oder andere Ändern; trotzdem sollte man weiter das Thema im Auge behalten.

Wenn man in einem SQL Server Integration Services Package mit einem parametrisiertem SQL Statement in einem OleDB Befehl gegen eine Oracle Datenbank arbeiten will, erhält man diese Fehlermeldung:

Fehler bei Datenflusstask [OLE DB-Befehl 1 [195]]: SSIS-Fehlercode 'DTS_E_OLEDBERROR'. OLE DB-Fehler. Fehlercode: 0x80040E51.

Ein OLE DB-Datensatz ist verfügbar. Quelle: 'OraOLEDB' HRESULT: 0x80040E51 Beschreibung: 'Der Provider kann keine Parameterinformationen ermitteln und SetParameterInfo ist nicht aufgerufen worden.'.

Fehler bei Datenflusstask [OLE DB-Befehl 1 [195]]: Zielspaltenbeschreibungen können nicht aus den Parametern des SQL-Befehls abgerufen werden.

Den Grund nennt die Fehlermeldung, der Oracle Treiber ist (trotz aktuellem Stand 11g) nicht in der Lage Metadaten für die verwendeten Parameter zurück zu liefern, also Informationen wie Datentyp etc.

Andere Provider können das hingegen problemlos.

Das ist nicht gerade schön, aber auch kein Beinbruch, man muss dann halt die Parameter selbst definieren und die Zuordnung manuell vornehmen.

Nehmen wir mal an, man will Daten in einer Oracle Tabelle aktualisieren, sei es über einen einfachen selbst definiert OleDB Befehl oder mit Einem, der aus dem Wizard der Transformation „Langsam veränderliche Dimension“ (SCD = Slowly Changing Dimension“) erzeugt wurde. Das parametrisierte Statement sieht dann im Prinzip so aus:

 UPDATE "Schema"."Tabelle"
SET "Feld1" = ?
  ,"Feld2" = ?
  ,"Feld3" = ?
  ,"Feld4" = ?
WHERE  "PK" = ? 

Wie allgemein bei OleDB Befehlen sind die Parameter nicht benannt, sondern es sind welche mit dem Fragezeichen Platzhalter und dadurch ist bei der späteren Zuordnung die Reihenfolge der Parameter wichtig.

Als erstes definiert man in den Eigenschaften des „OleDB-Befehl“ unter dem Kartenreiter „Eingabe- und Ausgabeeigenschaften“ die einzelnen Parameter mit dem jeweiligen Datentyp und dabei ist, wie zuvor erwähnt, die Reihenfolge wichtig. Das heißt für das Beispiel-Statement von oben, das erst die Felder „Feld1“ bis „Feld4“ definiert und zum Schluss der PK Parameter, da der „? Parameter“ im SQL Statement auch zuletzt kommt.

Ebenso wichtig ist natürlich, das man die Datentypen richtig definiert, sonst gibt es später bei der Überprüfung bzw. beim Ausführen mindestens Warnungen, wenn nicht gar Fehler.

Dann ordnet man noch schnell unter dem Kartenordner „Spaltenzuordnung“ die Eingabespalten den Parametern zu und das war es schon; anschließend gibt es keine Fehlermeldung oder Warnungen beim Erstellen des Packages und der OleDB Befehl arbeitet wie gewünscht.

Einen Hinweis aber noch:
Wurde der OleDB Befehl vom Wizard der Transformation „Langsam veränderliche Dimension“ erstellt, dann diesen später nicht noch einmal aufrufen, denn der verwirft dann alle manuellen Änderungen und man darf wieder alles von vorne durchgehen.

Microsoft hat mit der Microsoft® SQL Server® code name 'Denali', Community Technology Preview 3 (CTP 3) Product Guide eine sehr umfangreiche Sammlung an Whitepaper, Präsentationen, Videos, Linksammlungen und mehr zum SQL Server „Denali“ veröffentlich; eine Zusammenfassung kann man im SQL Server Blog nachlesen.

Der Download ist 456 MB groß, entpackt sind es 503 MB. Etwas durchgeblättert habe ich schon, der Aufbau ist sehr ansehnlich gestaltet und bei der Fülle an Informationen kann man sich damit durchaus ein paar Tage beschäftigen; genau das richtige fürs anstehende voraussichtlich verregnete Wochenende.

Die neue Microsoft® SQL Server® Codename 'Denali' Community Technology Preview 3 (CTP 3) steht zum Download zur Verfügung und das auch auf Deutsch; natürlich für x86 und x64 Systeme.

Nicht verwirren lassen, man muss zunächst die "SQL DMS DE.html" herunterladen, auf der Seite findet man dann den weiterführenden Link. Der Download-Manager erfolgt dann über ein Download-Manager AddIn. Für x86 ist der Download 2,3 GB groß.

Ein aktuelles Feature Pack gibt es dazu. Man beachte auch, was in Denali / CTP 3 neu ist.

Microsoft hat sein Online Fortbildungsprogramm (E-Learning) um die Microsoft Virtual Academy (MVA) erweitert, der man kostenlos bei treten kann.

Momentan werden 4 Kurse angeboten, die sich alle um die Cloud drehen, also um Windows Azure, dabei ist auch ein Kurs zu SQL Azure. Die Kurse beziehen sich inhaltlich mehr auf technologische und administrative Aspekte von Azure, Themen zur Entwicklung sind nicht dabei, das wird nur etwas am Rande behandelt.
Wenn man einen Kurs startet, muss man die Lektionen einen nach dem anderen abarbeiten, wobei die Kursmaterialen aus PDF Dokumenten und WebCasts bestehen. Als Abschluss jedes Kurses kann man eine Prüfung (Self-Assessment) ablegen, dabei werden 5 – 7 Fragen gestellt, die man innerhalb 10 Minuten beantworten muss. Für jede gestartete Lektion und für jede erfolgreich abgeschlossene Prüfung gibt es Punkte, wobei es für die Prüfungen immer die volle Punktezahl gibt, auch wenn ein oder zwei Fragen falsch beantwortet wurden. Von daher sagt die volle erreichte Punktezahl nur aus, das man alles abgearbeitet hat, aber nicht wie gut … mal abgesehen, das man nebenher schummeln könnte und die Antworten im Netz suchen könnte.
Es ist halt nur zur Selbstkontrolle gedacht; eben ein Self-Assessment.

Ich hatte es ich letzten Blog Artikel bereits erwähnt, das erste Probleme im Zusammenhang mit dem Microsoft Visual Studio 2010 Service Pack 1 gemeldet wurden.

Einer muss ja Versuchskaninchen sein und deshalb habe ich mal auf meinem Rechner das Service Pack 1 installiert; zu updaten gab es MS Visual Basic 2010 Express Edition, MS C# 2010 Express Edition und MS Visual Web Developer 2010 Express Edition, sowie diverse Redistributables. Die Installation per WebInstaller lief gut eine Stunde und das völlig reibungsfrei ab.

Erste tests im SSMS 2008 R2 ergaben nun: Tabellen, Views, Stored Procedures und Funktionen werden weiterhin von IntelliSense aufgelistet, aber keine Feldnamen mehr. Parameterinfo funktioniert ebenfalls wie gehabt.

Vor der Installation des SP 1 sollte man aich also zunächst überlegen, ob man mit der Einschränkung leben kann. Ein Komfort-Verlust ist es, aber meines Erachtens auch nicht so tragisch.

Kürzlich ist das Microsoft Visual Studio 2010 Service Pack 1 erschienen. Grundsätzlich neige ich dazu, Service Packs auch zu installieren, neben Benefits wie Stabilität, Performance und Sicherheit bieten sie manchmal auch neue Features.

In diesem Fall ist aber etwas Vorsicht geboten, denn den ersten Rückmeldungen in MSDN Foren wie

SSMS 2008 R2 IntelliSense Stopped Working after VS 2010 SP1

zufolge hat das Service Pack eher negative Auswirkungen auf das SSMS = Sql Server Management Studio; IntelliSense funktioniert anschließend nicht mehr.

Das CU6 für Sql Server 2008 R2 soll das Problem beheben. Aber das kann es ja nun eigentlich nicht sein, das man sich mit einem Service Pack sich Probleme einholt, die man mit einem weiteren CU erst wieder beheben muss. 

Man hört und sieht es immer noch häufiger:

Auch heutzutage, wo jedem das Thema Sicherheit präsent sein sollte, gibt es weiterhin viele, kleine oder größere Applikationen, die auf einen MS SQL Server zugreifen und das mit dem SQL Account "sa", welcher nicht zu selten über kein strenges oder noch schlimmer, über gar kein Passwort verfügt; mal abgesehen davon, dass es eh jeder kennt. Dabei ist dieser Standard SysAdmin Account eigentlich sowieso auch nur für die Administration gedacht gewesen; wie es halt immer so ist.

Natürlich sollte sowas von Grund auf geändert werden, also das die Anmeldung über den Windows Account des aktuellen Benutzers erfolgt oder zumindest über einen für die jeweilige Applikation dediziert angelegten SQL Account, der über ein strenges Passwort verfügt.

Durch die Masse an Applikationen ist eine solche Änderung natürlich zeitaufwendig; und was ist in der Zwischenzeit, bis alle Zugriffe geändert sind? Weiterhin dieses Sicherheitsrisiko eingehen mit der Gefahr, dass jemand "ungewünschte Änderungen" vornimmt und Daten oder gar ganze Objekte löscht?

Dafür gäbe es eine Möglichkeit zur Lösung. Seit dem Microsoft SQL Server Version 2005 gibt es die Möglichkeit SQL Account‘s mittels eines einfach ALTER LOGIN umzubenennen, einschließlich dem "sa" Account.

Die Idee ist also folgende:

-       "sa" umbenennen, z.B. in "saRealAdmin"

-       Strenges Passwort für "saRealAdmin" vergeben

-       Neuen SQL Account "sa" mit dem ursprünglichen Passwort anlegen und ihm die minimalst benötigten Rechte geben.

Versuchen wir es mal (Empfehlung: Vorher die [master] Datenbank kopieren!):

 USE [master] 

 GO 

 -- Original "sa" umbenennen 

 ALTER LOGIN [sa] WITH NAME = [saRealAdmin] 

 GO 

 -- Neuen "sa" mit altem Pwd anlegen 

 CREATE LOGIN [sa] WITH PASSWORD=N'altesPasswort' 

 GO 

 -- Kontrolle; beide da 

 SELECT sid, name 

 FROM [master].[sys].[syslogins] 

 WHERE name LIKE 'sa%' 

 GO 

 -- In AdventureWorks als DB User anlegen 

 -- und nur Lese-Rechte vergeben 

 USE [AdventureWorks] 

 GO 

 CREATE USER [sa] FOR LOGIN [sa] 

 GO 

 EXEC sp_addrolemember N'db_datawriter', N'sa' 

 GO 

 -- Test neuer "sa" auf Rechte 

 EXECUTE AS LOGIN = 'sa'; 

 GO 

 DROP TABLE Person.Address 

 GO 

 -- User Context wieder zurück schalten 

 REVERT; 

Der Test hat geklappt, die Anmeldung mit dem neuen „sa“ funktioniert, die Rechte sind eingeschränkt und auch die Verwendung des vermeintlich alten „saRealAdmin“ funktioniert einwandfrei und hat natürlich weiterhin Admin-Rechte.

Auf die Art kann man die Zwischenzeit überbrücken und trotzdem arbeiten Applikationen, die „sa“ verwenden weiterhin.

Nach Umstellung aller Apps sollte man sich überlegen, die Umbenennung rückgängig zu machen, sonst denkt der Admin womöglich nicht mehr daran, einen andern Sql Account zu verwenden.

Wie man im offiziellen Blog von Microsoft "Data Platform Insider" lesen kann, soll der MS SQL Server 2008 R2 im Mai 2010 released werden:
SQL Server 2008 R2 gets an official date

Nach etwas längerer Zeit wollte ich mal wieder an meinem eigenen Add-In für das SSMS (Microsoft SQL Server Management Studio) arbeiten und wurde plötzlich beim Öffnen des Projektes mit reichlichen Fehlermeldungen begrüßt.

Es wurde mokiert, das IObjectExplorerEventProvider nicht definiert sein und ServiceCache.GetObjectExplorer() kein Member ist. Ein Blick in den Objektbrowser zeigte schnell, dass es sie wirklich nicht mehr gibt. Beide sind im Namespace Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer der DLL SqlWorkbench.Interfaces.dll enthalten (liegt in C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\SqlWorkbench.Interfaces.dll).

Tja, und der Grund ist, dass ich inzwischen Microsoft SQL Server 2008 R2 CTP 3 November installiert habe und im dem Zuge eben die DLL von Version 10.0.1600.22 auf 10.5.1352.12 aktualisiert wurde. Da es ein Minor-Release (oder weil es eine CTP) ist, gibt es keinen eigenen Ordner wie 105, sondern es wurde in dem Ordner von MS SQL Server 2008 installiert. So gestaltet sich eine Parallelinstallation von 2008 und 2008 R2 als problematisch; bisher was immer unkritisch war.

Bisher habe ich noch keine weiteren Hinweise oder Work-a-rounds gefunden; da recherchiere ich noch.

ObjectExplorer mit Stand MS SQL Server 2008

Und mit Stand MS SQL Server 2008 R2 CTP3; da fehlt was zwischen INotifyWhenAddedToTree und IObjectExplorerService.

Also, wer versucht ein Add-In für MS SQL Server 2008 R2 SSMS zu installieren und es funktioniert nicht; daran liegt es.