Connection zu SQL Server Express über lokales Netzwerk..Wie?

[mikhal]

Servername besteht aus <Servername> und <Instanzname>, durch einen Backslash getrennt. Bei einer Standardinstallation von SQL Server 2005 wird eine Instanz SQLEXPRESS angelegt.

Also etwa "Mittelerde\SQLEXPRESS" (wenn dein Server Mittelerde heißt).

Grüße
Mikhal

[edit]Bist du dir eigentlich sicher, daß die Firewall auf deinem Server deine Anfrage durchläßt?[/edit]

[marabu]

Hallo Tom,

ich bezweifle nicht, dass du dich mit dem LDAP-Port deines Servers lokal und remote verbinden kannst, aber das ist doch gar nicht das was du willst. Ich rate dir auch nochmal (Beiträge #29, #41) die Firewall auf dem Server zu untersuchen. Die Verbindung ist in deinem Sinn erst erfolgreich, wenn du dich mit dem SQL Server verbinden kannst, also lass AD aus dem Spiel.

Bei einer Standardinstallation würde ich den Instanznamen weglassen.

Freundliche Grüße vom marabu

[torud]

Also mein Server ist ja eigentlich nur ein ganz normaler Win2000-Rechner. Auf dem System selbst ist nicht einmal eine Firewall installiert. Vielleicht aber im Netzwerksystem selbst? Wie kann ich denn überprüfen, ob die Anfragen beim Server ankommen? Gibt es da eine LogDatei oder ähnliches, wo der Server so was aufzeichnet? Oder wie würdet Ihr das überprüfen?

[mikhal]

Check mal das Ereignis-Protokoll beider Rechner, vielleicht findest du dort eine aufschlußreiche Fehlermeldung.

[marabu]

Weil ich befürchte, dass ich nicht richtig verstanden wurde, hier nochmal in aller Klarheit: es ist offensichtlich noch kein einziges mal gelungen eine Verbindung zum SQL Server aufzubauen. Durch die Verwendung des OLE DB Providers für Microsoft Directory Service hat Tom sich mit dem Verzeichnisdienst auf seinem "WIN2K Server" verbunden. Beim Versuch sich mit dem korrekten Provider auf den SQL Server zu verbinden meuterte die Netzwerkbibliothek wegen irgendwelcher Konfigurationsprobleme im Named Pipes Protokoll. Ich schlage vor, dieses Protokoll auf SQL-Server- und DB-Client-Seite zu deaktivieren. Um zu überprüfen, ob der Port 1433 auf dem Server überhaupt erreichbar ist, würde ich über Telnet eine Verbindung mit dem Server herstellen.

marabu

[torud]

Also ich habe nun sogar auf beiden Rechnern den gleichen Anmeldenamen und das gleiche PW vergeben, um auch noch das auszuschliessen, obwohl es nicht nötig gewesen wäre.

Anschliessend habe ich versucht mit cmd und von dort aus mit Telnet PCName 1433 den Server zu kontaktieren. "Verbinden fehlgeschlagen" lautete die Meldung!

Ich habe also unsere Netzwerkabteilung angerufen. Unsere Firewall ist nur nach aussen hin tätig und hausintern sind alle Ports frei und offen. Langsam wirds komisch.

Das Ereignisprotokoll zeigte mir nichts auffälliges!

Und hier noch ein Update zur Fehlermeldungsfront. Es gab mal was neues, bei meinem letzen Versuch:
"Fehler beim Testen der Verbindung durch einen Fehler beim Initialisieren des Providers. Der Client kann die Verbindung nicht aufbauen"

Gibt es irgendetwas, was ich vielleicht auf dem Client installieren muss oder auf Aktualität überprüfen muss?

[marabu]

Wenn du das Setup für SQLExpress auf dem Client ausgeführt hast, dann wurde eigentlich alles geprüft. Wie ich bereits schrieb funktioniert in der Regel die Standardinstallation ohne weitere Probleme. Daraus würde ich aus der Ferne schließen, dass du die Installation entweder gar nicht oder nicht richtig durchgeführt hast.

Können deine Kollegen von der Netzwerkabteilung dir überhaupt nicht helfen?

marabu

[mikhal]

Ist auf dem Client eigentlich die MDAC installiert (und vor allem die aktuellste?). Die Fehlermeldung läßt darauf schließen, daß das nicht der Fall ist. Schau mal bei Microsoft nach der aktuellsten MDAC.

Grüße
Mikhal

[torud]

Also an Alle, die hier fleissig mitgelesen, mitgebangt und durch Infos geholfen haben. Jetzt endlich geht es. Es ist mir schon mehr als peinlich, aber ich gebe hier nun ganz offen zu, dass es an der MDAC lag. Ich hatte natürlich eine installiert, sicher sogar eine über der 1.0, aber scheinbar nicht die 2.8.

Ich habe sie also nach dem letzten Hinweis gezogen und installiert, den Client neu gestartet und schon als ich die Liste mit den Servern öffnete, lachte mich die gesamte Serverliste der Firma an. Anschliessend habe ich sicherheitshalber noch die Testsoftware gestartet, welche sich mit dem Server verbindet und ich erhielt alles, was ich wollte. Super!

Bitte nicht sauer sein! :oops:

[boserPascal]

Hallo!

Da ich selbst das Problem hab auf eine SQL-Server zu verbinden bin ich auf diese Diskussion aufmerksam geworden. Das Problem zu verbinden habe ich soweit gelöst, dass ich bei System-DNS in ODBC ein Verweis angelegt habe. Die TDatabase Komponente findet diesen auch und schreibt verbunden. Nur muß ich vorher eine Datenbank anlegen, wie geht das in dieser Express Edition. Dann noch eine Frage zu SQL in Delphi. Ich habe vorher mySQL direct genommen um Datenbankabfragen zu machen das geht wie bei PHP sehr einfach und ohne zusätzliche Treiber. Gibt es für MS SQL Server auch so eine Variante? Eine kleine Anregung wie ich die SQL abfragen über die TDatabase Komponente realisiere wäre mir sehr willkommen!

Vielen Dank im vorraus!

[marabu]

Herzlich willkommen in der Delphi-PRAXiS, boserPascal.

Das Anlegen einer Datenbank ist über Transact-SQL (T-SQL) möglich. Dazu verbindest du dich einfach mit der Master-Datenbank und verwendest das CREATE DATABASE Statement. Hier im Forum findest du sicher einige Code-Beispiele, wenn du nach ADO Ausschau hältst.

Ganz ohne "Treiber" geht es wohl nicht, aber was du vielleicht meinst ist die Programmierung gegen das Call Level Interface (CLI, DB-Library). Diese Programmiertechnik aus der Zeit von SQL Server 6.5 (und frühere Versionen) wurde in der Microsoft-Welt durch die Bereitstellung höherer Abstraktionen (ADO, RDO, ODBC, OLEDB) obsolet.

Im oben verknüpften Beispiel findest du eine ADOQuery mit fest eingetragenem SQL. Du kannst das SQL-Statement natürlich auch zur Laufzeit festlegen:

Delphi-Quellcode:

begin
  with ADOQuery do
  begin
    SQL.Text := 'SELECT * FROM employees';
    Open;
  end;
end;

Freundliche Grüße vom marabu

[boserPascal]

Danke für die Antwort!

Ich hab eigentlich schon den ODBC Treiber gemeint, wenn man aber win2000 als Industriestandard voraussetzt gibt es da keine Probleme weil ODBC standardmäßig eingebaut ist. Ich hatte mir nur Sorgen um eine einfache Einrichtung der Software gemacht.
Solange ich mit einfachen SQL-Statements arbeiten kann, gibt es kein Problem.
Ich werd später zuhause die Lösung gleich ausprobieren. Was mir noch aufgefallen ist der Datenbankname scheint zwar Pflicht zu sein aber egal ob vorhanden oder nicht. Und ich kann entweder den Treiber oder den Alias auswählen heißt das ,das der Treiber über den Alias ermittelt wird?
Dann noch eine Verständnisfrage, der MS SQL Server dient wohl nur als Ablagemappe für die Datenbanken da man keine Verwaltungstools dazubekommt? Der einzige Zugriff ging über Visual Studio, welches ich aus Performancegründen gelöscht hab.
Und Visual C++ 6 hat die Server-Anbindung nicht.

[marabu]

Zum MS SQL Server gehört das MMC-SnapIn Enterprise Manager - nur die Desktop Variante des MS SQL Server kommt ohne Verwaltungstool daher, weil man bei MS davon ausging (siehe EULA), dass alle Verwaltungsfunktionen in den Client eingebaut werden sollten.

Eventuell möchtest du dir ja mal den EMS SQL Manager for SQL Server anschauen: trial

marabu

[boserPascal]

Also ich hab nun das Beispiel geöffnet und ich krieg nun folgende Fehler:

Folgende Klassen wurden nicht gefunden:
Klasse TADOConnection
Klasse TADOQuery

ADO welches laut Hilfe mit den Komponenten oben in der Toolbox stehen müßte ist auch nicht vorhanden. Liegt das an der Pro Version, weil Delphi 5 ist es ja oder muß man es nachinstallieren!

DBGrid zeigt jetzt was an. Danke für die Hilfe, falls weitere Fragen auftreten melde ich mich.