TADOConnection mit SystemDSN? Problem...

[stho]

Hallo Leute,
ich hab das Problem das ich in einem Service mich alle XX Minuten mit einer Datenbank über die ODBCs verbinden möchte...
Jedoch hab ich jetzt als Service das Problem das ich keine Benutzer-DSNs anlegen sondern nur System-DSNs anlegen kann.
Somit erzeuge ich einen DSN (der beim Testen über den integrierten ODBC-Administrator) auch funktioniert.
("Verbindung testen" -> Verbindung erfolgreich)

Jedoch wenn ich eine ADOConnection im Service erzeuge und den Connectionstring auf den DSN zuweise
("Provider=MSDASQL.1;Persist Security Info=False;Data Source=MyDSN")
dann sagt er mir mit einer Fehlermeldung "DSN nicht gefunden!"

Was mache ich falsch? Kann ich ihm irgendwie explizit sagen das es sich bei dem DSN um einen System-DSN handelt und nicht um einen Benutzer-DSN?
Oder benötige ich besondere Berechtigungen?

Info:
Ich benutze WinXP SP3 mit D2007
Es kommt leider keine andere Verbindung als die ADO-Komponenten in Frage...

Währe sehr dankbar für eine Antwort :-)

[Bernhard Geyer]

Zitat:

Zitat von stho (Beitrag 1041116)

Jedoch wenn ich eine ADOConnection im Service erzeuge ...

Wie erzeugst du diesen?

Zitat:

Zitat von stho (Beitrag 1041116)

Es kommt leider keine andere Verbindung als die ADO-Komponenten in Frage...

Aber muss es über ODBC gehen? MS SQL Server und Access geht direkt und bevor du MySQLODBC oder ODBC für Oracle installierst, installier doch den ADO/OLE DB-Provider dafür.

[stho]

Wie ich das erzeuge:

Delphi-Quellcode:

  ADO := TADOConnection.Create(nil);
  ADO.LoginPrompt      := False;
  ADO.KeepConnection   := False;
  ADO.ConnectionString := 'Provider=MSDASQL.1;Persist Security Info=False;Data Source='+sName;
  ADO.Connected        := True;

-> Jedoch tritt der Fehler bei "ADO.Connected := True" auf :-(

und nein, leider kommt eine andere Lösung nicht in betracht...

[mkinzler]

Und was für einer?

[stho]

Zitat:

[...] Fehlermeldung "DSN nicht gefunden!"

Um genau zu sein:
"Fehler bei der syntaktischen Analyse: DSN 'MyDSN' existiert nicht!"

Daraus schließe ich mal das er den DSN unter Benutzer-DSNs sucht denn dort ist er ja NICHT vorhanden...
(Wie oben beschrieben ist der Eintrag als SystemDSN hinterlegt)

Daher ja auch meine Frage im Titel: Wie kann ich einen System-DSN mit den ADOs ansprechen :wink:

[Bernhard Geyer]

[QUOTE=stho;1041169]Wie ich das erzeuge:

Falsch verquotet. Meinte:

Zitat:

Zitat von stho (Beitrag 1041169)

Somit erzeuge ich einen DSN (der beim Testen über den integrierten ODBC-Administrator) auch funktioniert.

Wie erstellst du den DSN-Eintrag.

Zitat:

Zitat von stho (Beitrag 1041169)

und nein, leider kommt eine andere Lösung nicht in betracht...

Es kommt nur ODBC in Betracht auch wenn es nicht vernünftig geht? Es sinnvollere Wege gibt. ...
Da kann ich mir dann meine Zeit sparen

[stho]

Zitat:

Wie erstellst du den DSN-Eintrag.

Direkt in die Registry mit der TRegisry-Klasse von D2007
Welche genauen Werte ich eintrag darf ich leider nicht ansprechen... tut mir leid :(
Aber ich kann dir folgendes sagen:
"HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\MyD SN" (Und hier halt die benötigten Werte rein)
Danach noch einen Eintrag in
"HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODB C Data Source" als Value "MyDSN"

Zitat:

Da kann ich mir dann meine Zeit sparen

Natürlich kannst du das... jeder schreibt hier freiwillig... :wink:
aber da ich mich nunmal an gewisse dinge halten muss die mir mein chef vorgibt kann ich daran auch nichts ändern... ^^

Hoffe ich konnte deine Fragen beantworten

[Bernhard Geyer]

Zitat:

Zitat von stho (Beitrag 1041176)

Zitat:

Wie erstellst du den DSN-Eintrag.

Direkt in die Registry mit der TRegisry-Klasse von D2007
Welche genauen Werte ich eintrag darf ich leider nicht ansprechen... tut mir leid :(
Aber ich kann dir folgendes sagen:
"HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\MyD SN" (Und hier halt die benötigten Werte rein)
Danach noch einen Eintrag in
"HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODB C Data Source" als Value "MyDSN"

Wird nicht genügen. Und man sollte sowas über die WinAPI erledigen.
Ich Tipp darauf das der ODBC-Administrator beim Aufruf einfach die fehlerhafte Konfiguration korrigiert.

Zitat:

Zitat von stho (Beitrag 1041176)

aber da ich mich nunmal an gewisse dinge halten muss die mir mein chef vorgibt kann ich daran auch nichts ändern... ^^

Und wenn der Chef sagt: "Spring aus dem Fenster" dann machst du das auch? Solche nicht mehr zeitgemäßen Vorgaben sollte man auch mal hinterfragen. Denn was vor 10/20 Jahren sinnvoll war ist nicht unbedingt im Jahre 2010 mehr sinnvoll. Evtl. weiß der Chef ja auch nicht das ODBC eigentlich schon wieder eine veraltete Technik ist und bei diversen DB's eigentlich nur noch minimal unterstützt wird (z.B. hat MS vor kuzren jegliche Treiberunterstützung für Oracle abgekündigt so das irgendwann der standardmäßig installierte MS-Oracle-Treiber verschwinden wird.

[stho]

Zitat:

Ich Tipp darauf das der ODBC-Administrator beim Aufruf einfach die fehlerhafte Konfiguration korrigiert.

Nein, ausgeschlossen...
Wenn ich ein normales Programm erstelle (Kein Service) und ich die ADO-Connection mit den im
Service genutzten ConnectionString sich verbinden lasse funktioniert es.
Und ja, die beiden Einstellungen beider Objekte sind vollkommen identisch... einziger Unterschied liegt darin das
die eine ADO-Connection im Service erzeugt wird und die andere in einem normalen Programm

Zitat:

Und wenn der Chef sagt: "Spring aus dem Fenster" dann machst du das auch?

-> Nein

Zitat:

Solche nicht mehr zeitgemäßen Vorgaben sollte man auch mal hinterfragen.

-> Habe ich...
Aber das lass mal meine sorge sein :wink:
Denn das ist ja im Moment nicht Sinn meiner Fragestellung wenn ich das mal so einwerfen darf ^^

[Bernhard Geyer]

Zitat:

Zitat von stho (Beitrag 1041201)

Und ja, die beiden Einstellungen beider Objekte sind vollkommen identisch... einziger Unterschied liegt darin das
die eine ADO-Connection im Service erzeugt wird und die andere in einem normalen Programm

Sollte zwar ander Fehlermeldung kommen, aber schreib mal in deinem Service ein CoInitialize(nil);