ADOConnection wieder öffnen und ConnectionString neu zuweisen

[Jumpy]

Hallo,

hab ein internes Programm das mit ADOConnection auf eine DB-Zugreift. Das ist beliebter als ursprünglich gedacht und geplant und läuft bei vielen Kollegen den ganzen Tag. Es hält dabei aber ständig die Verbindung zur Datenbank offen, was mittleweile lästig wird und eigentl. nicht nötig ist.

Also wird die ADOConnection jetzt nach dem Start geschlossen und nur bei Bedarf wieder geöffnet.
Dazu muss ich aber jedesmal der Connection den ConnectionString neu zuweisen. Mach ich das nicht, so kommt bei einem Connection.Open die Fehlermeldung von der Datenbank, dass Benutzername und Passwort falsch sind. Ich hab dann gesehen, das in der ADO-Komponente am Ende der Open-Prozedur die internen Felder für Benutzer und Passwort "geleert" werden (:='') und ich hab mich gefragt, warum ist das so? Was ist der Sinn?

[sx2008]

Die Open Methode der AdoConnection müsste es in einer überladenen Version geben.
adoconnection1.Open(user, password);
Das ist einfacher als User & Password in den ConnectionString einzubauen.
User & PW werden wahrscheinlich aus Sicherheitsgründen aus dem ConnectionString entfernt.
Diess könnte auch Providerspezifisch sein und vom Oracle OLE-DB Provider ausgehen.

[jobo]

Trägst Du in der Connection Werte für "Persist security Info" ein?
Das ist glaub ich per default = false, erst bei True werden User/pw im connection string abgelegt. Das wäre ggF unproblematisch, solange der String selbst nicht wiederum irgendwo gespeichert wird.

[Bernhard Geyer]

Oracle und Zugriff über ADO/OLE DB? Ist eh eine schlechte Kombination?
Der Treiber von MS wurde schon vor Jahren aufs Altengleis geschoben und ist eh eher eine Technologiestudie als für den produktiven Einsatz geeignet.

[jobo]

Zitat von Bernhard Geyer:

Oracle und Zugriff über ADO/OLE DB? Ist eh eine schlechte Kombination?
Der Treiber von MS wurde schon vor Jahren aufs Altengleis geschoben und ist eh eher eine Technologiestudie als für den produktiven Einsatz geeignet.

Es wäre natürlich bzw. seit einiger Zeit der Oracle Treiber zu empfehlen.

[arnof]

vorher mach mal dass:

ConnectionString:='';


Wenn ich hier was mache und z.B. bei einer TADOTable auf eine andere Tabelle zugreifen will mache ich vor dem Open Grundsätzlich:

Connection:=nil;
ConnectionString:='';

Sonst behält er irgendwie immer was irgendwo im Cash ....

[arnof]

Zitat von Bernhard Geyer:

Oracle und Zugriff über ADO/OLE DB? Ist eh eine schlechte Kombination?
Der Treiber von MS wurde schon vor Jahren aufs Altengleis geschoben und ist eh eher eine Technologiestudie als für den produktiven Einsatz geeignet.

Es gibt ständig aber neue und die werden auch gepflegt (in WIN8.1 und SQL Server 2013)

[Jumpy]

Zitat von Bernhard Geyer:

Oracle und Zugriff über ADO/OLE DB? Ist eh eine schlechte Kombination?
Der Treiber von MS wurde schon vor Jahren aufs Altengleis geschoben und ist eh eher eine Technologiestudie als für den produktiven Einsatz geeignet.

Also der tatsächliche Zugriff geht via ADO -> Oracle's ODBC -> Oracle DB. Ist nicht ideal, haben wir auch glaub ich schon drüber geredet, aber ich hab's noch nichrt geschafft, die etablierten Kollegen zu einer Änderung des ganzen Frameworks über das die internen Programme laufen zu überreden.

Zitat von jobo:

Trägst Du in der Connection Werte für "Persist security Info" ein?
Das ist glaub ich per default = false, erst bei True werden User/pw im connection string abgelegt. Das wäre ggF unproblematisch, solange der String selbst nicht wiederum irgendwo gespeichert wird.

Im ConnectionString (hab gerade mal nachgeguckt) wird sogar explizit 'Persist Security Info=False;' angegeben und ich denke da liegt dann auch der Hund begraben. Da muss ich nun aber die Kollegen fragen, was denen lieber ist, ob wir das mal auf true setzen, oder ob wir mal die Prozedur abändern wie die Connection erzeugt wird. Das ist das, was ich testweise gemacht habe.

Im Hintergrund ist nämlich ein Datenmodul, quasi wie ein Singelton verwendet, wo man eine Connection anfordern kann. Hat es die Connection schon in ihrem Pool, gibt sie sie raus, ansonsten wird sie erzeugt, dem Pool hinzugefügt und dann rausgegeben. ConnectionString, bzw. Anmdeldeinfos kommen dabei aus einer dll, wodurch wohl irgendwie die Geheimniskrämer hier befriedigt werden sollen, auch wenn das wohl auch nicht mehr ganz zeitgemäß ist.
Da hab ich jetzt einfach mal die Prozedur zur Connectionanforderung so angepasst, dass sie bei einer bereits vorhandenen Connection prüft, ob diese geschlossen ist und falls ja, weist sie einfach nochmal den ConnectionString zu.
'Persist security' Info auf true setzen wär natürlich irgendwie einfacher.

Sollen mal die Kollegen entscheiden. Bzw. wenn ihr Gedanken dazu habt immer her damit, dann hab ich ggf. Argumente für und wieder, und vllt. hört man dann mal auf mich

[Bernhard Geyer]

Zitat von arnof:

Zitat von Bernhard Geyer:

Oracle und Zugriff über ADO/OLE DB? Ist eh eine schlechte Kombination?
Der Treiber von MS wurde schon vor Jahren aufs Altengleis geschoben und ist eh eher eine Technologiestudie als für den produktiven Einsatz geeignet.

Es gibt ständig aber neue und die werden auch gepflegt (in WIN8.1 und SQL Server 2013)

Ich spreche nicht von Ado(.net) im allgemeinen sondern den MS-Treiber für Oracle von MS.

Zitat von Jumpy:

Also der tatsächliche Zugriff geht via ADO -> Oracle's ODBC -> Oracle DB. Ist nicht ideal, haben wir auch glaub ich schon drüber geredet, aber ich hab's noch nichrt geschafft, die etablierten Kollegen zu einer Änderung des ganzen Frameworks über das die internen Programme laufen zu überreden.

Ok. Der dürfte halbwegs gehen. Besser wäre natürlich native Kompos wie von DevArt einzusetzen.

[p80286]

Mit dem OraOleDB.Oracle als ADO-Provider habe ich wenig Probleme.

Und Du (Bernhard) darfst ein nicht vergessen,für ADO entstehen keine zusätzlichen Kosten.
Zumindestens wenn man als DV-Hilfsarbeiter tätig ist, ist das ein Argument gegen das Du wenig entgegenzusetzen hast.

Gruß
K-H