Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Prism Connection String aufbauen (https://www.delphipraxis.net/71070-connection-string-aufbauen.html)

Alexander 8. Jun 2006 12:26

Datenbank: Unterschiedlich • Zugriff über: ADO.NET

Connection String aufbauen
 
Hallo,
ich habe eine Frage zu den Connection Strings und zwar gibt es doch diesen "Connection String Builder", der z.B. aufgeht, wenn man im OI den Connection String einstellen will.
Ich lasse diesen jetzt auch in meinem Programm anzeigen. Dies mache ich recht einfach, indem ich eine *.UDL erzeugen lassen und diese anzeige. Eigentlich recht simpel.
2 Dinge stören mich jedoch ganz gewaltig:
- man kann vorher scheinbar keinen Provider einstellen bzw. er geht gleich auf die zweite Seite und hat immer den "Microsoft OLE-DB Provider for ODBC-Drivers" als Standard hinterlegt.
- Ich nutze derzeit nur die OdbcConnection, OdbcCommand etc.. Klassen von .NET.. Und da erzeugt er mir ja leider auch den falschen String.
Beispiel:
Code:
Data Source=Wall;Persist Security Info=False (das erzeugt der aus Delphi (OI) heraus aufgerufene Dialog)

Provider=MSDASQL.1;Persist Security Info=False;Data Source=Wall (das kommt aus meinem Programm)

DSN=wall;UID=wwwrun;PWD= (das brauche ich)
Der Connection String ist ja deswegen falsch, da er den für einen OLE Provider aufbaut. Aber welchen Provider muss ich sonst nehmen?
Ich schätze, wenn ich entsprechenden OLE Klassen unter .NET verwenden würde, würde es mit diesem String auch klappen, aber das will ich nicht ;).

Ich wollte eigentlich vermeiden mir einen eigenen Dialog zu bauen, obwohl das wahrscheinlich das beste wäre ...
Habt ihr Ideen, wie man das vernünftig realisieren kann?
Grüße, Alexander

Bernhard Geyer 8. Jun 2006 20:24

Re: Connection String aufbauen
 
Kann es sein das du auf dem Holzweg bist?

ADO.NET hat bis auf die ersten 3 Buchstaben nichts mehr mit ADO gemeinsam. Auch der gescheiderte MS-Versuch mittels einer Klasse in deinem Programm das über einen Connection-String diverse DB's ansprechen kann und damit Problemlos funktioniert ist gescheidert.

Unter ADO.NET mußt du mit unterschiedlichen Zugriffsklassen arbeiten (z.B. SQLConnection für den MS-SQL-Server) und erst auf Ebene der Datasets ist die Quelle der Daten egal. Du must unter ADO.NET 1.1 einiges an Handarbeit durchführen und für jede DB z.B. eine Zugriffsklasse schreiben.

Erst solche Systeme wie ECO, hibernate oder ich glaube ADO.NET 2.0 nehmen dir einige Arbeit ab um mit mehreren DB's arbeiten zu können.

Alexander 11. Jun 2006 13:46

Re: Connection String aufbauen
 
Hallo Bernhard :)
das war mir durch klar. Und ich verwende z.B. auch die SQL...-Klassen und die Oracle...-Klassen. Nur möchte ich auch per ODBC all die anderen Datenbanken unterstützen.
Das Problem ist jedoch, dass ich einen Dialog benötige, der mir diese Connection-Strings erzeugt (durch Eingabe von Datenbank, Server etc.. oder einfach nur den DSN). Und die Connection-Strings sind ja größtenteils gleich geblieben. "DSN=wall;UID=wwwrun;PWD=" habe ich z.B. auch schon unter ADO genutzt ;).
Ich habe halt nur gedacht, man könne diesen vorgefertigten Dialog weiterhin benutzen, weil Delphi das eben auch macht.
Daher suche ich halt die Möglichkeit, solche Strings automatisch zu erzeugen.
Gibt es da etwas vorgefertigtes oder muss ich tatsächlich selbst diesen Dialog erzeugen?

Bernhard Geyer 11. Jun 2006 17:35

Re: Connection String aufbauen
 
Du hast doch die Pro-Version. Schau halt mal in den Sorucen der ADO-Units nach welche WinAPI-Funktion hierfür aufgerufen wird.

Alexander 22. Jun 2006 12:27

Re: Connection String aufbauen
 
Leider konnte ich erst jetzt wieder zu diesem Thema kommen.
Da ich ja die .NET-Connection Objecte nehme (z.B. SQLConnection), gibt es dazu ja keine Sourcen von Borland. Daher kann ich da ja leider auch nicht abkucken...

Bernhard Geyer 22. Jun 2006 20:18

Re: Connection String aufbauen
 
Ich würde generell wenn Du schon ADO.NET nimmst auf keinen Fall auf das "altsystem" ADO zurückwelchesen. Deine Idee alle anderen DB's zu unterstützen kann nur für sehr einfache Anwendungen funktionieren da die Datenbanke sich ja in der SQL-Syntax unterscheiden und es damit besser ist wenn eine DB xy gefordert ist für diese einen ADO.NET-Provider zu suchen und diesen dann in der DB-Access-Schicht deiner Anwendung einbinden.

Alexander 22. Jun 2006 20:54

Re: Connection String aufbauen
 
Ich denke da hast du recht. Ein paar verschiedene Datenbanken wollte ich aber schon unterstützen. Selbst wenn ich noch die SQL-Statements ein wenig anpassen muss.
Für den Aufbau der Connection-String werde ich mir wohl selber etwas zusammen bauen müssen :?. Wenn ich mich da auf die wesentlichen Datenbanken beschränke, wird das wohl gehen.
Die Strings selber sind ja auf http://www.connectionstrings.com/ recht gut beschrieben.

Wenn es aber schon Klassen dafür geben sollte, werde ich diese natürlich nehmen... Mir ist nur bisher keiner bekannt (bisauf der von ADO)

Vielen Dank noch mals für deine Beiträge.

winnionkel 20. Nov 2006 08:11

Re: Connection String aufbauen
 
Hallo, ist zwar schon länger her, das du gefragt hast, aber probier das hier:

EditConnectionString(ADOConnection);

Du mußt dafür die Unit 'AdoConEd' einbinden.

Gruß winni

Alexander 21. Nov 2006 14:25

Re: Connection String aufbauen
 
Ich habe jetzt aber zwar nicht nachgeforscht oder es ausprobiert, meine mich aber zu erinnern, dass das in die VCL Welt gehörte und damit für mich so nicht zu verwenden, da ich ja Delphi.NET benutze.
Vielleicht täusche ich mich ja auch :)

Vielen Dank auf jeden Fall dennoch.

winnionkel 21. Nov 2006 14:50

Re: Connection String aufbauen
 
Kann ich dir jetzt auch nicht sagen, da ich von .NET 0 Ahnung habe.
Hatte die Funktion hier aus dem Forum.
Du kannst ja mal danach suchen. Vielleicht steht da mehr drüber.

gruß winni


Alle Zeitangaben in WEZ +1. Es ist jetzt 04:58 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz