Benutzer mit den meisten Antworten
Windows 7 (64Bit) / SQL Server 2008 Express (64Bit) / System-DSN Datei 64 Bit nicht möglich

Frage
-
Hallo zusammen,
ich habe einen Rechner mit Windows 7 (64Bit) Ultimate und eine SQL Server 2008 Express Datenbank, die auch auf 64Bit läuft. Nun versuche ich eine ODBC Quelle hinzuzufügen.
Beim Start des Programmes C:\Windows\SysWOW64\odbcad32.exe kann ich eine Verbindung herstellen. Dies ist ja eigentlich der 32Bit Pfad.
Beim Start des Programmes C:\Windows\System32\odbcad32.exe kann ich keine Verbindung herstellen. Also die 64Bit Schiene funktioniert nicht. Ich erhalten der Fehler, dass der angegebene SQL-Server nicht erreichbar ist.
Beim Erstellen eines Programmes in VS2008 habe ich nun das Problem, dass ich ein Projekt erstellen muss, dass x86 ist anstatt x64, weil VS2008 sonst mit der 32Bit System-dsn nicht klar kommt.
Wie kann ich eine 64Bit System-dsn anlegen, und diese auch nutzen? Die Beiträge hier im Forum und auch bei Google konnten mir nicht weiter helfen.
Ich hoffe ich habe mich verständlich ausgedrückt.
Vielen Dank und Gruß
Martin
Antworten
-
Hallo,
in solchen Fällen ist es sinnvoller ein Provider Modell zu verwenden,
und die jeweiligen nativen Treiber zu verwenden, für Oracle wäre das ODP .NET ClientUnter http://msdn.microsoft.com/en-us/library/ms972319.aspx
findet sich ein älteres Beispiel - da käme aber noch einges mehr auf Dich zu ;-)
Eine Möglichkeit die das bereits beinhaltet wäre die Enterprise LibraryDenn die Unterschiede enden nicht bei der Verbindungszeichenfolge.
Auch SQL Anweisungen uam. differieren über kurz oder lang.
Und als gemeinsamen Nenner kann die Anwendung dann die Db... Klassen
über die 'DbProviderFactory' (ADO.NET) oder die (älteren) IDb-Schnittstellen verwenden.Und die Anwendung selbst kommunziert dann über Repositories Klassen als Data Layer.
Willst Du Dich damit nicht selbst auseinandersetzen, wäre der Einsatz eines
ORMs wie z. B. Entity Framework oder NHibernate oft die bessere Alternative.Gruß Elmar
- Als Antwort markiert Robert BreitenhoferModerator Donnerstag, 2. Dezember 2010 11:43
-
Hallo Marcin,
wenn MDLAPTOP funktioniert, nicht aber MDLAPTOP\MD_SQLEXPRESS
so dürfte der SQL Server auf Deinem 64-Bit Rechnerentweder als unbenannte Standard-Instanz
oder aber auf dem Standard-Port 1433 laufen -
Letztere wird wegen der Grundeinstellungen bei der Server-Netzwerkkonfiguration gefunden.
Um das zu klären (sollte man für sich selbst schon wissen),
schau mal in den SQL Server KonfigurationsmanagerDort findest Du die Namen für die installierten Instanzen
und auch ihre Netzwerk-Konfiguration.Gruß Elmar
- Als Antwort markiert Robert BreitenhoferModerator Donnerstag, 2. Dezember 2010 11:43
Alle Antworten
-
Hallo Marcin,
und warum legst Du nicht in Deinem VS-Projekt mittels eines Connection-Objekts eine Verbindung an?
In VS kannst Du doch mittels SQL Native Client auf die Datenbank zugreifen!
Uwe Ricken
Microsoft Certified Database Administrator SQL Server 2005
db Berater GmbH
http://www-db-berater.de -
Hallo,
ich wollte es mir einfach machen und somit eine Datenbankunabhängigkeit einfach realisieren. Sobald das Tool auf Oracle zugreift, dann müsste ich nix ändern, wenn die dsn gleich heißt.
Beim Connection Objekt muss ich ja eine Auswahl treffen, welcher Connection String genommen werden muss.
Die Variante mit dem dsn fand ich am Anfang charmanter. Aber ich befürchte, dass war zu voreilig.
-
Hallo zusammen,
Problem bleibt leider auch beim Aufruf aus VS2008 bestehen.
Hier nochmal die Situation:Auf unseren Server läuft ein SQLServer2008 Express mit 32Bit (auf SBS 2008 (64Bit)).
Ich habe mir einen SQLServer2008 Express auf meinen Rechner mit 64Bit installiert (Betriebssystem Windows 7 ultimate (64Bit)).
Ich versuche nun mit folgenden SQL mich mit der Datenbank zu connecten:
C#-Code:
StringBuilder OLEDB_sb = new StringBuilder();
OLEDB_sb.AppendLine("Provider=SQLOLEDB.1;");
OLEDB_sb.AppendLine("Password=********;"); //Passwort unkenntlich gemacht
OLEDB_sb.AppendLine("Persist Security Info=True;");
OLEDB_sb.AppendLine("User ID=********;"); //User unkenntlich gemacht
OLEDB_sb.AppendLine("Initial Catalog=master;");
OLEDB_sb.AppendLine("Data Source=kisocon-sc1430\\SQLEXPRESS");
Der Connect auf den Server mit der 32 Bit Installation funktioniert. Ändere ich den Server auf meine lokale 64Bit Installation, dann funktioniert dieser nicht und gibt mir folgende Meldung zurück:
[DBNETLIB][ConnectionOpen (Connect()).]Der angegebene SQL Server konnte nicht gefunden werden.
Beim Anlegen einer DSN Datei als ODBC Quelle habe ich gleiches Problem:
- Connect mit C:\Windows\System32\odbcad32.exe (Pfad für ODBC 64 Bit) klappt nicht.
- Connect mit C:\Windows\SysWOW64\odbcad32.exe (Pfad für ODBC 32 Bit) klappt.
Hat da einer vielleicht eine Idee? Mit dem Management Studio vom SQLServer 2008 (Installation 32 Bit) kann ich beide Datenbanken ansprechen und mich connecten. -
Hallo Marcin,
Da Du schreibst, die Verbindung funktioniert nicht, wenn Du "meine lokale 64Bit Installation" verwendest,
so solltes Du überprüfen, ob bei Dir lokal der SQL Server Browser Dienst läuft.
Der ist dafür zuständig, die notwendigen Informationen zu ermitteln.Für eine lokale Express Instanz kannst Du auch (local)\SQLEXPRESS als Verbindungszeichenfolge einsetzen.
Bei der obigen Verbindungszeichenfolge ist ODBC überhaupt nicht involviert,
denn OleDb verwendet die Treiber/Informationen dort nicht. Um zu prüfen
ob OleDb richtig registiert ist, verwende etwas wie:
http://blogs.msdn.com/b/farukcelik/archive/2007/12/31/udl-test-on-a-64-bit-machine.aspx
(Und SSMS verwendet den SqlClient)Wenn Du Ole Db verwenden willst/mußt, so solltest Du die aktuelleren Treiber aus
dem Native Client verwenden, denn nur dort werden alle Features unterstützt -
SQLOLEDB ist veraltet und existiert nur aus Kompatibilität zum alten MDAC.
Die Treiber sind auch als separate Downloads als Teil des Feature Packs verfügbar:
Microsoft® SQL Server® 2008 R2 Feature PackUnd zuletzt: Eine Verbindungszeichenfolge in .NET solltest Du besser mit dem
OleDbConnectionStringBuilder erstellen. Das vermeidet einige Stolperfallen.
(Und verwendest Du den SqlClient gibt es dort einen SqlConnectionStringBuilder )Gruß Elmar
-
Ahhhhh sry mein Fehler. Hab den falsche Code rauskopiert.
Ich versuche in meinem kleinen Tool einen Connect über OleDB und einen über ODBC herzustellen.
StringBuilder sb = new StringBuilder(); sb.AppendLine("Driver={SQL Server};"); sb.AppendLine("Server=kisocon-sc1430\\SQLEXPRESS;"); sb.AppendLine("Database=master;"); sb.AppendLine("UID=********;"); //User unkenntlich gemacht sb.AppendLine("PWD=********;"); //Passwort unkenntlich gemacht
Habe dummer Weise den OleDB Code rauskopiert, der btw. auch nicht funktioniert. Oben ist der ODBC String. Könnte sein, dass ich da den anderen Treiber Native Cleint ansprechen muss?
Als Dienste sind gestartet: "SQL Server" / "SQL Server Browser" / "SQL Server VSS Writer"
Die oben genannten SQl Features werde ich mal ausprobieren. Melde mich dazu dann nochmal.
-
Hallo Marcin,
Du solltest Dich schon auf eine Schnittstelle einigen ;-)
Am sinnvollsten wäre der SqlClient - u. a. hier weil weniger Abhängigkeiten
zu externen Bibliotheken existieren (und er i. a. am schnellsten ist).
Siehe auch: SQL Server und ADO.NETAuf ODBC und OleDb sollte man bei .NET und SQL Server nur dann zurückgreifen,
wenn es aus anderen Gründen (unterschiedliche RDBMS etc.) notwendig ist.Der Native Client ist auch für ODBC verfügbar (dort sind OleDb wie ODBC in einer DLL integriert)
siehe u. a.: Aktualisieren einer Anwendung von MDAC auf SQL Server Native ClientGruß Elmar
-
Die Idee war, das ich eine LKlasse für den Connect zu SQLServer und zu Oracle baue. Also entweder komplett OleDB oder ODBC.
Wenn ich jetzt den SQLClient nehme, dann muss ich nen kompletten anderen Aufruf für den Connect nutzen, weil der SQLClient (.Net Klasse) ja nicht Oracle kann.
Also so wie ich das i.M. verstehe wäre für meinen Fall eine ODBC Lösung mit ansprechen des Native Clients bzw. des Oracle Clients am sinnvollsten. Ich hoffe ich verstehe Deine Posts richtig. Beschäftige mich erst recht kurz mit dem Thema. War vorher Hardcore ACCESS Programmierer. ;)
-
Hallo,
in solchen Fällen ist es sinnvoller ein Provider Modell zu verwenden,
und die jeweiligen nativen Treiber zu verwenden, für Oracle wäre das ODP .NET ClientUnter http://msdn.microsoft.com/en-us/library/ms972319.aspx
findet sich ein älteres Beispiel - da käme aber noch einges mehr auf Dich zu ;-)
Eine Möglichkeit die das bereits beinhaltet wäre die Enterprise LibraryDenn die Unterschiede enden nicht bei der Verbindungszeichenfolge.
Auch SQL Anweisungen uam. differieren über kurz oder lang.
Und als gemeinsamen Nenner kann die Anwendung dann die Db... Klassen
über die 'DbProviderFactory' (ADO.NET) oder die (älteren) IDb-Schnittstellen verwenden.Und die Anwendung selbst kommunziert dann über Repositories Klassen als Data Layer.
Willst Du Dich damit nicht selbst auseinandersetzen, wäre der Einsatz eines
ORMs wie z. B. Entity Framework oder NHibernate oft die bessere Alternative.Gruß Elmar
- Als Antwort markiert Robert BreitenhoferModerator Donnerstag, 2. Dezember 2010 11:43
-
Super danke für die Hilfe. Habe dann jetzt mal ordentlich was zum Lesen. Wenn Fragen kommen, dann komme ich nochmal auf das Thema hier zurück.
Habe auch mittlerweile einen Connect hinbekommen. Ich verstehe zwar nicht wieso das so ist, aber vielleicht kann mir ja auch da jemand helfen.
Ich habe beim Connect String die Instanz weggenommen.
Vorher (Datenbank läuft auf 32Bit)
Funktioniert:
Server=MDLAPTOP\MD_SQLEXPRESS
Jetzt (Datenbank läuft auf 64Bit)
Funktioniert nicht:
MDLAPTOP\MD_SQLEXPRESS
Funktioniert:
MDLAPTOP
Wie gebe ich dem denn jetzt mit, wenn ich 2 Instance von dem SQLServer2008 Express habe?
-
Hallo Marcin,
wenn MDLAPTOP funktioniert, nicht aber MDLAPTOP\MD_SQLEXPRESS
so dürfte der SQL Server auf Deinem 64-Bit Rechnerentweder als unbenannte Standard-Instanz
oder aber auf dem Standard-Port 1433 laufen -
Letztere wird wegen der Grundeinstellungen bei der Server-Netzwerkkonfiguration gefunden.
Um das zu klären (sollte man für sich selbst schon wissen),
schau mal in den SQL Server KonfigurationsmanagerDort findest Du die Namen für die installierten Instanzen
und auch ihre Netzwerk-Konfiguration.Gruß Elmar
- Als Antwort markiert Robert BreitenhoferModerator Donnerstag, 2. Dezember 2010 11:43
-
Hallo Elmar,
das mit dem Konfigurationsmanager war der Tipp schlecht hin. Hab mir mal rein interesses halber den Native Client 10 aufgeklappt und dort den Bereich Alias angeschaut. Ich weiß nicht, wie es zustande gekommen ist, denn ich wußte nicht mal, dass dieser Bereich existiert. Aber hier die Lösung meines Problemes:
Im Alias Bereich stand folgendes:
Alias Server
MDLAPTOP MDLAPTOP\MD_SQLExpress
MDLAPTOP\MD_SQLEXPRESS \MD_SQLExpress
habe jetzt die ganzen Alias gelöscht und komme mit MDLAPTOP\MD_SQLExpress im Connection String drauf.
Danke für die, für mich sehr informative Kommunikation. Besonderer Dank an Dich Elmar. :TOP:
Hab viel gelernt.
Gruß
Martin