none
SQLDMO unter Windows 7 RRS feed

  • Frage

  • Meine Software lief jahrelang problemlos auf Windows XP. Sie benutzt den SQL Server 2005 Express (mittlerweile SP4) und die SQLDMO-Objekte per Visual Basic Skript.

    Zum Beispiel:

    Dim a
    Set a = CreateObject("SQLDMO.SQLServer")
    MsgBox "OK"

    Auf Windows 7 funktioniert der Aufruf nicht mehr. Ich erhalte immer den Fehler:

    ---------------------------
    Windows Script Host
    ---------------------------
    Skript:    ...
    Zeile:    ...
    Zeichen:    1
    Fehler:    ActiveX-Komponenten kann kein Objekt erstellen: 'SQLDMO.SQLServer'
    Code:    800A01AD
    Quelle:     Laufzeitfehler in Microsoft VBScript

    Ich habe alles kontrolliert. Zugriffsrechte für SQLDMO.DLL sind vorhanden, ebenso der Pfad dorthin in der PATH-Umgebungsvariablen.

    Wo ist das Problem? Was ist unter Windows 7 anders als unter Windows XP?

    Freitag, 7. Januar 2011 10:42

Antworten

  • Ich habe es nun mal unter Windows 2008 R2 64 Bit mit lokalen Admin-Rechten testen können; das dürfte zumindest halbwegs mit Windows 7 64 Bit vergleichbar sein.

    SQL seitig war nichts installiert, der Server wird für was anderes verwendet. Ich habe dann mal SQLServer2005_BC_x64 installiert und was soll sagen; es funktioniert problemlos. Ich kann per VBS eine Instanz von SQLDMO.SQLServer erzeugen und mich mit .Connect auch an einen SQL Server verbinden.

    Da fällt mir nun wirklich nichts mehr, woran es bei Dir hapern könnte.


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    • Als Antwort markiert Doreen Platz Mittwoch, 12. Januar 2011 09:03
    Mittwoch, 12. Januar 2011 06:01

Alle Antworten

  • Hallo Doreen,

    DMO ist noch vom SQL 2000!? Hattest Du die DLL nur auf den Rechner kopiert oder hattest Du es über die SQL 2000 Tools Installer mit installieren lassen?

    Das ist eine ActiveX-DLL, die über RegSrv32.exe registriert werden muss; eine Angabe eine Path-Variable bringt da nichts.

     


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Freitag, 7. Januar 2011 11:03

  • Doreen.Platz meinte:

    Fehler:    ActiveX-Komponenten kann kein Objekt erstellen: [...]
    Ich habe alles kontrolliert. Zugriffsrechte für SQLDMO.DLL sind vorhanden, ebenso der Pfad dorthin in der PATH-Umgebungsvariablen.

    Ist sie auch registriert?

    Christoph Sternberg */\

    Freitag, 7. Januar 2011 11:12
  • Hallo Christoph, hallo Olaf!

    Danke für die Antworten. Also: Ich mache alles wie immer: SQL Server 2005 Express with Advanced Services installieren, das bringt dann alles auf's System. Selbstverständlich kopiere ich nicht selber irgendwelche DLLs in irgendwelche Verzeichnisse. Und, ja, die Installation updated auch die Registry, sonst wäre sie ja nicht voll von SQLDMO....-Einträgen.

    Das Problem kann nicht an mir liegen, ich habe einen festen Installationsablauf (seit JAHREN), der unter Windows XP immer funktionierte. Dasselbe funktioniert jetzt unter Windows 7 nicht. Es ist auch nicht damit getan, dass ich das Testscript von oben "als Administrator" ausführe.

    Die Frage ist: Warum funktioniert in meinem Testskript z.B. "CreateObject('Scripting.FileSystemObject')", nicht aber "CreateObject('SQLDMO.SQLServer')"?

     

    Freitag, 7. Januar 2011 11:44
  • Hast Du zufällig Word oder Excel auf dem Rechner? Wenn, dann einmal starten, Alt+F11 drücken, damit kommst Du in den VBA Editor. Dann im Menü unter "Extras" => "Verweise" aufrufen. Findest Du dort einen Eintrag namens "Microsoft SQLDMO Object Library"? Wenn nicht, ist die SqlDmo.Dll nicht registriert.
    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Freitag, 7. Januar 2011 12:47
  • Nein, auf dem Entwicklerrechner gibt es kein Office. Das, was Du herausfinden willst, muss sich aber auch anders als mit Word oder Excel herausfinden lassen. Ausserdem ist ein REGSVR32-Aufruf immer erfolgreich (ich hab' ihn mittlerweile wer-weiss-wie-oft getan). Die SQLDMO.DLL ist mit Sicherheit registriert, weil ich in der Registry zum Beispiel den folgenden Eintrag finde: (SQLServer.8.0 ist synonym zu SQLServer)

    Windows Registry Editor Version 5.00

    [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{10020200-E260-11CF-AE68-00AA004A34D5}]
    @="SQLDMO Server"

    [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{10020200-E260-11CF-AE68-00AA004A34D5}\InprocHandler32]
    @="ole32.dll"

    [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{10020200-E260-11CF-AE68-00AA004A34D5}\InprocServer32]
    @="C:\\Program Files (x86)\\Microsoft SQL Server\\80\\Tools\\Binn\\sqldmo.dll"
    "ThreadingModel"="Both"

    [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{10020200-E260-11CF-AE68-00AA004A34D5}\ProgID]
    @="SQLDMO.SQLServer.8.0"

    [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{10020200-E260-11CF-AE68-00AA004A34D5}\VersionIndependentProgID]
    @="SQLDMO.SQLServer"

    Das Problem muss an irgendwelchen Zugriffsproblemen unter Windows 7 liegen. Nach der Installation des SQL Servers habe ich unter Windows XP immer das schon erwähnte Testskript laufen lassen - das lief immer fehlerfrei durch. Derselbe Ablauf scheitert unter Windows 7.

    Habt Ihr noch Ideen? Seltsamerweise gibt es im gesamten Internet keine ordentliche Antwort auf mein Problem. In einem KB-Artikel habe ich Dinge über Pfade (PATH-Variable) und Zugriffsrechte (UAC) gelesen, aber das trifft hier alles nicht zu, weil, wie schon erwähnt, unter Windows XP immer alles einfach funktionierte.

     

    Freitag, 7. Januar 2011 13:02
  • Das ist also auch noch ein 64 Bit Betriebssystem?

    Wie erwähnt, SqlDmo kommt vom SQL Server 2000: SQL Server 2000 and below are not supported on Vista/Windows Server 2008 and above (which includes Windows 7/Windows Server 2008 R2).

    Es kann also gut sein, das Du SqlDmo ab Vista nicht mehr verwenden kannst


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Freitag, 7. Januar 2011 13:16
  • Hallo Olaf!

    Ja, das ist ein 64-Bit-Betriebssystem. Und, nein, mein SQLDMO kommt NICHT vom SQL Server 2000, weil ich den gar nicht installiere. Ich installiere den SQL Server 2005 Express Edition with Advanced Services SP4. Der bringt sein SQLDMO mit. In dem von Dir angegebenen Artikel steht auch explizit drin, dass SQL Server 2005 von Windows 7 unterstützt wird. Und auf der Download-Seite für den SQL Server 2005 steht explizit, dass die Downloaddatei SQLEXPR_ADV_DEU.EXE (immerhin 269.4 MB groß) sowohl für 32-Bit- als auch für 64-Bit-Systeme geeignet ist.

    Es findet sich nirgends ein Hinweis darauf, dass SQLDMO nur mit 32 Bit funktioniert. SQLDMO wird zwar abgekündigt für die Nachfolger von SQL Server 2005 (man soll dann auf SMO wechseln) aber es wird nicht abgekündigt für Windows 7.

    Gibt es noch andere Ideen? Vielleicht könnte jemand ja einfach mal den SQL Server 2005 Express downloaden und unter Windows 7 installieren und das oben angegebene Skript ausführen :)

    Freitag, 7. Januar 2011 14:18
  • Und es wurde auch der SQL Server in der 64 Bit Version installiert?

    Was mich irritiert ist, das es scheinbar ein 32 Bit DLL ist (wegen den RegKeys in Wow).

    SqlDmo.DLL kann man mit den "Microsoft SQL Server 2005 Backward Compatibility Components" / "Abwärtskompatibilitätskomponenten" aus dem SQL Server 2005 SP 4 Feature Pack installieren, versuch es doch mal damit; gibt es als x86 und x64.


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Freitag, 7. Januar 2011 15:35
  • Mmh, ist das ein Problem? Der SQL Server ist wohl (korrekt) in C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL gelandet. Da kann man wohl von ausgehen, dass die WoW64-Umleitung funktioniert, oder? Das SQL Server Management Studio funktioniert ja auch, und der Server selber ebenfalls. Jedenfalls kann ich damit alles tun ("select * from orders" und solches Zeugs...) - nur eben mit meinem Testskript keinen "SQLDMO.SQLServer" instanziieren.

    Auf der Downloadseite vom SQL Server steht, man sollte das .NET Framework 2.0 installieren. Ich denke, das steht aber für solche Systeme wie Windows XP (auf dem ich das auch immer brav - problemlos - installiert habe). Wenn ich es downloade und auf meinem Windows 7 installieren will, verweigert es das mit der Meldung, es sei bereits als Teil des Betriebssystems installiert (NetFx64.exe).

    Freitag, 7. Januar 2011 15:57
  • Mmh, ist das ein Problem?

    Was, das Du die 32 Bit Version auf einem 64 Bit OS installiert hast? Das kann ich nicht sagen, so ein "System-Mensch" bin ich nicht. Aber da es eine x64 Version gibt, würde ich auch die installieren, zum einen weil es so gedacht ist und zum anderen, ein MischMasch kann eigentlich nur Probleme bereiten.

    Zur Info: Jetzt habe ich meinen Rechner mit MS Vista 32 Bit zur Hand, installiert ist SQL 2008 R2 Std 32 Bit und SqlDmo.DLL war nicht dabei. Ich habe die BC 2005 installiert, SqlDmo.Dll ist nun da und auch (vom Installer) registriert. Ich kann problemlos SQLDMO.SQLServer instanziieren; meine erste Vermutung vonwegen "not supported" können wir beseite schieben; es sein den Win 7 hat da noch Besonderheiten.

    SSMS wird SqlDmo eh nur dann verwenden, wenn Du versucht, auf eine SQL Server 2000 Instanz zuzugereifen; wozu sollte es auch für 2005 verwenden, da nutzt SSMS ebenfalls das aktuelle SMO. Das SSMS funktioniert ist keine Aussage über die Funktionsweise von SqlDmo.

    In Windows 7 sind von Haus aus alle benötigten .NET Versionen installiert, in der Richtung musst Du nichts nachinstallieren.

    Hast Du mittlerweile mal die 64 Bit Version aus den BC versucht?

    Ansonsten kann ich Dir nur empfehlen, Dich mal an ein eher System / Entwickler orientiertes Forum zu wenden, wie man eine 32 Bit DLL unter 64 OS zum laufen bringt; den soweit ich es bisher beurteilen kann, ist es kein wirkliches SQL Server / SqlDmo Problem.


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Freitag, 7. Januar 2011 18:00
  • Das ist jetzt eine Menge, also der Reihe nach:

    1) Ich habe die oben schon erwähnte SQLEXPR_ADV_DEU.EXE downgeloaded und installiert. Da kann ich nicht zwischen 32 Bit und 64 Bit wählen. Und dass die Installation nach "Program Files (x86)" installiert, ist völlig korrekt, glaube ich, schließlich ist das WOW64 extra dazu da, einer 32-Bit-Anwendung die Ausführung auf Windows 7 64 Bit zu erlauben.

    2) Dass Du mit Deinem " SQL 2008 R2 Std 32 Bit" KEIN SQLDMO auf den Rechner kriegst, ist klar, weil der SQL Server 2008 eben kein SQLDMO mehr mitbringt. Nach SQL Server 2005 ist das abgekündigt. Das ist für mich aber kein Problem, weil ich ja (noch) beim 2005er bleibe.

    3) Dass das SSMSE läuft, zeigt nicht, dass SQLDMO läuft oder nicht, da hast Du Recht. Aber es zeigt, dass die gesamte Installation läuft. Hätten wir es mit einem Problem an der 32-Bit-64-Bit-Front zu tun, dann liefe weder das SSMSE noch der Server selber. Das heisst (jedenfalls für mich), dass die Probleme mit dem SQLDMO eben nicht von da herrühren, sondern: Irgendetwas mit Zugriffsrechten unter Windows 7 zu tun haben.

    4) Danke für den Hinweis auf die .NET-Versionen. Nicht wahr, die hat Windows 7 schon im Bauch. Ich hatte schon Sorge, dass das .NET Framework 2.0 nicht auf dem Rechner ist, weil man es nirgendwo sieht.

    Ich mache jetzt Feierabend. (Ich bin völlig entnervt.) Ich werde noch einmal nachsehen, ob es doch einen expressis verbis 64-Bit-Download gibt, allerdings glaube ich nicht recht daran. Ich weiss eigentlich gar nicht, was für ein Problem ich habe. Die Maschine, auf der ich installiere, ist eine NAGELNEUE Installation, da ist also auch nichts kaputt. Und nirgendwo steht etwas derart, dass SQL Server 2005 NICHT auf Windows 7 laufen soll.

    Vielen Dank erst einmal für die geduldige Hilfe, Olaf! Ich wäre NOCH DANKBARER :), wenn Du vielleicht noch andere Erkenntnisse mitteilen könntest. Thanx!

    Öhm, es liegt aber nicht daran, dass ich das Windows 7 in einer virtuellen Maschine unter VMWare Player laufen habe, oder DOCH?

    Freitag, 7. Januar 2011 18:28
  • Also wenn ich unter den Systemvoraussetzungen von Microsoft SQL Server 2005 Express Edition Service Pack 4 nachlese, wird Windows 7 unterstützt, auch mit x64, nur IA64 nicht. SP4 ist dafür aber Voraussetzung.

    Es gibt auch einen separaten 32 Bit Installer, der "normale" ist, wenn ich es richtig interpretiere, für 32 und 64 Bit gedacht und läuft dann unter WoW.

    Andere haben scheinbar das gleiche Problem unter 64 bit, z.B. how to manually register a 64 bit version of SqlDmo.dll, nur eine richtige Lösung habe ich bisher auch noch nicht gesehen. Nach den System Requirements for SQL-DMO und Wie verteilen und installieren Sie SQL-DMO für SQL Server 2000 werden lediglich noch die ODBC Treiber als Abhängigkeit benötigt, sollte aber auch nicht das Problem sein.


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Montag, 10. Januar 2011 09:40
  • hallo Doreen,

    Problem schon gelöst?

    Es ist auch nicht damit getan, dass ich das Testscript von oben "als Administrator" ausführe.

    Wie hast du es getestet?

    Du musst mit einem Konto angemeldet sein, welches in der lokalen Administratorengruppe ist und starte das Skript im Explorer mit dem Kontextmenü "Ausführen als Administrator". In manchen Fällen ist beides notwendig.

    Die Frage ist: Warum funktioniert in meinem Testskript z.B. "CreateObject('Scripting.FileSystemObject')", nicht aber "CreateObject('SQLDMO.SQLServer')"?

    Eigentlich habt ihr die drei Hauptursachen schon durch:

    1. DLL nicht vorhanden / registriert
    2. DLL nicht im Suchpfad des Prozesses
    3. Fehlende Berechtigungen

    Dann gibt es noch das Problem mit fehlerhaften Installation/Registrierungen, das ist allerdings schwer nachzuvollziehen. Testest du auf einer frisch aufgesetzten Windows 7 Maschine? btw, welches Windows 7 wird denn genau verwendet (Home, Pro, Ultimate, de, en, 32bit, 64bit)?

    Ist die WSH-Installation in Ordnung? Lass mal folgendes in einem als Administrator gestarteten Prompt durchlaufen:

    regsvr32 vbscript.dll
    regsvr32 wshom.ocx
    regsvr32 scrrun.dll


    Microsoft MVP Office Access
    https://mvp.support.microsoft.com/profile/Stefan.Hoffmann
    Montag, 10. Januar 2011 10:10
    Moderator
  • Hallo und Guten Abend!

    Das Problem ist immer noch nicht gelöst. Ich habe es genau so getestet, wie beschrieben: Von einem lokalen Administrator-Konto aus UND per "Als Administrator(in) ausführen". Nichts. Bloß, dass der Fehlercode (seit wann?) nicht mehr 800a01ad lautet, sondern 80040154. Es handelt sich um eine NAGELNEUE Maschine (eine virtuelle Maschine unter VMWare), gerade einmal mit einem frischen Windows 7 Home Premium installiert, sonst ist auf der Maschine noch NICHTS passiert, abgesehen von der Installation des SQL Servers natürlich. Der 1. und 3. REGSVR32-Aufruf funktionieren ordentlich, der 2. nicht (WSHOM.OCX). Was heisst das?

     

    Montag, 10. Januar 2011 21:54
  • hallo Doreen,

    Bloß, dass der Fehlercode (seit wann?) nicht mehr 800a01ad lautet, sondern 80040154.

    Der Fehlercode steht für "Class not registered", siehe

    http://msdn.microsoft.com/en-us/library/dd542643%28v=vs.85%29.aspx

    Es handelt sich um eine NAGELNEUE Maschine (eine virtuelle Maschine unter VMWare), gerade einmal mit einem frischen Windows 7 Home Premium installiert, sonst ist auf der Maschine noch NICHTS passiert, abgesehen von der Installation des SQL Servers natürlich.

    Ist in der von dir installierten Version des SQL Servers 2005 schon das SP3 enthalten? Wenn nicht, hast du es schon instlliert?

    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ae7387c3-348c-4faa-8ae5-949fdfbe59c4&displaylang=en
     > Der 1. und 3. REGSVR32-Aufruf funktionieren ordentlich, der 2. nicht (WSHOM.OCX). Was heisst das?
    Das ist der Windows Scripting Host.

    http://www.activevb.de/tutorials/tut_wsh/wsh.html


    Microsoft MVP Office Access
    https://mvp.support.microsoft.com/profile/Stefan.Hoffmann
    Dienstag, 11. Januar 2011 11:10
    Moderator
  • Ich habe es nun mal unter Windows 2008 R2 64 Bit mit lokalen Admin-Rechten testen können; das dürfte zumindest halbwegs mit Windows 7 64 Bit vergleichbar sein.

    SQL seitig war nichts installiert, der Server wird für was anderes verwendet. Ich habe dann mal SQLServer2005_BC_x64 installiert und was soll sagen; es funktioniert problemlos. Ich kann per VBS eine Instanz von SQLDMO.SQLServer erzeugen und mich mit .Connect auch an einen SQL Server verbinden.

    Da fällt mir nun wirklich nichts mehr, woran es bei Dir hapern könnte.


    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    • Als Antwort markiert Doreen Platz Mittwoch, 12. Januar 2011 09:03
    Mittwoch, 12. Januar 2011 06:01
  • DAS WAR'S!

    Danke, Olaf!

    Ich habe vom "Feature Pack for Microsoft SQL Server 2005 SP4" die von Dir erwähnte BC (Backward Compatibility) downgeloaded (heisst bei mir "DEU\x64\SQLServer2005_BC.msi", 18,5 MB) und damit explizit die SQLDMOs installiert, und - schwupps - funktioniert alles!

    Kaum macht man's richtig, schon geht's...

    Warum war das jetzt so schwierig?

    Vielen Dank jedenfalls, jetzt komme ich endlich weiter.

     

    Mittwoch, 12. Januar 2011 09:13