ein paar m�glichkeiten bieten sich da schon an..
nunja,. �ber sinn und unsinn einer jeden m�glichkeit l�sst sich wahrlich
streiten... deswegen liste ich dir die vermeintlich "besten" mal auf
1.: der einfachste weg
wie in der antwort von rene angesprochen:
du definierts deine ado-funktionen in einem modul (kein klassenmodul).
damit kannst du dann von jeder klasse aus, auf diese zugreifen.
leichteste �bung dabei ist ein globales conn-object im modul zu definieren
Public conn As New ADODB.Connection
nachteile liegen aber ganz klar auf der hand. ressourcensparend oder gar
objektorientiert(orientiert wohlgemerkt) ist dieser weg nicht unbedingt.
2.: etwas anders
du definierst eine neue klasse, die nur f�r den datenzugriff zust�ndig ist.
nach aussen gibt es kein connection-objekt. alle abfragen werden �ber daf�r
erstellte funktionen(sowas geht nat. auch im modul)
in den einzelnen klassen, die auf diese zugriff haben sorgst du per
eigenschaft(set) daf�r, dass diese auch zugriff auf diese bekommen.
beispiel:
clsDB ist deine datenbank-zugriffsklasse
in deiner klasse 2 steht sowas in der art
Private m_dbObject as clsDB
Public Property Set dbObject(Value As clsDB)
Set m_dbObject = Value
End Property
Private Sub Class_Terminate()
set dbObject = Nothing
'darf in diesem Fall auf keinen Fall vergessen werden. ;)
'die aufr�umarbeiten(Class_Terminate) gehen in der klasse clsDB
'erst dann los, wenn keine einzige Referenz mehr auf ein Objekt
'dieser klasse da ist!!
End Sub
beim erstellen deines "haupt"-objekts, musst du ein db-objekt erstellen.
beim erstellen der anderen klassen musst du dieses erstellte objekt �ber die
eigenschaft dbObject weitergeben(nat. nur f�r die klassen, in denen dies
gebraucht wird)
3.: ganz anders, aber gleich
der letzte weg ist dem 2. sehr �hnlich aber weitaus komplexer und
umfangreicher.
allerdings w�rde ich, wenn du deine objekte ab und zu weitergibst/verkaufst,
und sich dadurch auch die datenbank und damit die
abfragen/zugriffstechniken(oledb(provider?), odbc) �ndern, dein db-objekt
extern setzten.
das klappt im eigentlichen auch so, wie ichs gerade vorgestellt habe. nur
wenn diese dann auch noch unterschiedlich hei�en sollen(zb clsDBAccess,
clsDBSQLServer..), dann wirds zeit f�r ein interface namens IclsDB.
ein Interface ist eine "leere" klasse, die nur aus den r�mpfen der anwendung
besteht.
also zb sowas
Klasse IclsDB in externem activex-dll-Projekt namens MeinInterface. (das I
steht f�r Interface,. sollte man einhalten, sonst wirds schnell
un�bersichtlich)
Public Function Connect(ByVal UserName As String, ByVal Password As String)
As Boolean
'
End Function
das anf�hrungsstrichchen ist nur dazu gut, dass der Compiler diese Funktion
auch ber�cksichtigt..
nun machst du ein neues (activex-dll)Projekt und nennst die darin enthaltene
klasse clsSQLServer(alles nur vorschl�ge*g*)
in den projektverweisen musst du nun auf die oben genannte
dll(MeinInterface) verweisen(theoretisch geht auch das projekt, aber vb6
h�ngt dann manchmal)
als erstes Statement kommt in die klasse das inherits-statement vor.
Inherits MeinInterface.IclsDB
nun erscheint in deinem codefenster in der ersten combobox unter "Class"
auch "IclsDB".
dies ausgew�hlt erscheinen in der 2. combobox alle funktionen und
eigenschaften, die du im interface definiert hast.
Diese m�ssen alle(!!) in dieser dll vorkommen(also minimum ein
kommentarzeichen), damits kompiliert werden kann.
letztendlich kommen wir zum schluss.
da nun alle deine db-klassen (also clsDBAccess, clsDBSQLServer) zum
Interface IclsDB konform sind(und dies auch durch inherits sichergestellt
ist), kannst du perfekt damit arbeiten.
dein projekt,welches nun auf die ganzen db-zugriffs-klassen zugreifen will,
muss auch einen verweis auf die interface-dll(MeinInterface) haben.
und nun zur�ck zu beispiel 2:
statt clsDB schreibst du nun eben MeinInterface.IclsDB
der rest ist late-bindung �ber createobject(nur in deiner "haupt"-klasse)
du l�dst deine spezielle klasse(zb clsSQLServer) dann mittels
Dim m_dbObject as MeinInterface.IclsDB
Set m_dbObject = CreateObject("Projektname.clsSQLServer")
du kannst nat. zuvor sicherstellen, dass die klasse auch registriert wird
und vorhanden ist. du kannst auch nachschauen, welche dll vorhanden ist, und
diese nehmen, oder nat. auch die spezielle klasse in deine projektverweise
aufnehmen(und das createobjekt dadurch weglassen).
mit letzterer variante m�sstest du aber wieder f�r jedes db-system neu
kompilieren.. mit createobject m�sstest du "einfach" die zugriffsdll�s
weitergeben
ein fehler wird ausgel�st, wenn 1. die klasse nicht registriert ist, und 2.
die klasse nichts mit dem Interface gemein hat, also nicht von diesem
abgeleitet ist.
wenns mal mehrere versionen geben soll ist eine ableitung von min. 2
interfacesd sinnvoll(IclsDBInfo), wobei die 2. nur die versionsnummer
tr�gt(oder so)
auch wenn es sich nicht unbedingt so anh�rt. es funktioniert ;)
wolfgang
http://www.vbwelt.de/
| [aspdecoffeehouse] als [email protected] subscribed
| http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
