Access-DB Tabellen- und Querydefinitionen als Quellcode (Konstantendefinitionen) generieren Der Zugriff auf Tabellen und Queries von VB aus beruht auf dem Prinzip Hoffnung. Hoffnung, dass alle Felder und Tabellen so vorhanden sind, wie sie im Quellcode angegeben werden. Das hier gezeigte Tool, soll den Entwickler unterstützen, in dem es entsprechende Konstantendefinitionen erzeugt.
Autor:   Dirk Siebert	Bewertung:     [ Jetzt bewerten ]	Views:  16.290
ohne Homepage	System:  WinXP, Win7, Win8, Win10, Win11	Beispielprojekt

Geben Sie hier Ihre persönliche Bewertung ab! Bisher wurde noch keine Bewertung abgegeben.

sehr gut     gut     nützlich     mittelmäßig     mangelhaft

Eine Datenbank mit ~40 Tabellen und einer enstprechenden Menge an Abfragen kann einen Entwickler bei Umstrukturierungen den Schweiß auf die Stirn treiben. Das größte Problem ist hierbei, dass kein Editor oder Compiler zur Entwicklungszeit prüfen kann, ob ein Zugriff auf z.B. ein Feld korrekt ist.
Also wie z.B. der Zugriff mittels rsMeinRecordset("EinFeldName"). Ein fehlerhafter Feldname fällt erst zur Laufzeit auf!

Der erste Schritt war also in einem Modul Konstanten zu definieren:

Public Const TDEF_LF_Components_lngID As String = "lngID"

Vom Ansatz her gut, beinhaltet aber eigentlich genau das gleiche Problem, wie bereits oben beschrieben. Ich habe zwar nun Konstanten und bin guter Hoffnung, dass es so mit der entsprechenden Tabellendefinition passt. Kann aber natürlich auch nicht sicher sein. Der einzige Vorteil ist hier, dass ich den Feldnamen nur an einer Stelle ändern muss!

Nach dem ich einige Zeit nach einem Tool für ORM (Object Relational Mapping) für VB6 gesucht hatte und keines fand, kam ich auf die Idee ein kleines Hilfsprogramm zu schreiben, welches mir Konstanten-Definitionen aus Tabellen- und Query-Definitionen generiert.

Ich möchte nun meinen nicht perfekten und sicherlich nicht sehr gut kommentierten Quellcode zur Verfügung stellen, da ich denke, dass dieser hilfreich ist. Zum Einen als Anwendung um eben Konstanten-Definitionen zu generieren zum Anderen um einfach mal zu schauen, wie ein anderer Entwickler codiert.

Folgendes ist bei der Definition der Tabellen und Querries zu beachten (und kann im Quellcode natürlich geändert werden):

• Systemtabellen werden ausgeschlossen. Siehe Function WriteTblDefs, Klasse CDbTransformer
• Tabellen, welche bei der Generierung berücksichtigt werden sollen, müssen mit einem Präfix beginnen, welcher in CDbTransformer.Class_Initialize() in das entsprechende Dictionary eingetragen wurde
• Querries, welche bei der Generierung berücksichtigt werden sollen, müssen mit einem Präfix beginnen, welcher in CDbTransformer.Class_Initialize() in das entsprechende Dictionary eingetragen wurde

Konstanten für Parameter-Querries werden ebenfalls generiert. Außerdem verwende ich Tabellen, welche Typen darstellen und bei der Generierung in Enums umgewandelt werden.

Bsp. Tabellenname: tblType, Beschreibung enthält "TYPETABLE"
Felder:
   ID: Zahl, Autowert, Primary Key, Beschreibung enthält "TYPEID"
   Name: String, Index eindeutig, Beschreibung enthält "TYPENAME"

Datensätze:

ID Name
-----------
1 Test1
2 Test2

Ergebnis des Generators (Tabellendefinition (oben) und Typdefinition):

' ******************************************************************************* 
Public Const TDEF_Type As String = "tblType" 
Public Const TDEF_Type_ID As String = "ID" 
Public Const TDEF_Type_Name As String = "Name" 
 
Public Enum gt_Type 
  Test1 = 1 
  Test2 = 2 
End Enum

Damit der Generator weiß, dass es sich um eine Tabelle handelt, welche als Enum transformiert werden soll, muss die Tabellendefinition folgendermaßen erfolgen (siehe Function isTypeTable, Klasse CDbTranformer):
Die Tabelle muss

• in der Beschreibung den String "TYPETABLE" aufweisen
• ein Feld namens "lngID" aufweisen ODER ein Feld muss in der Beschreibung den String "TYPEID" aufweisen
• ein Feld namens "strType" aufweisen ODER ein Feld muss in der Beschreibung den String "TYPENAME" aufweisen.

Das Prüfen der Strings ist nicht case sensitiv. Der Generator erzeugt ein Modul für Tabellen (inkl. Enums) modDbTblDefs.bas und ein Modul für Querries modDbQryDefs.bas. Es erfolgt kein Check, ob ein generierter Enum mit z.B. einem reservierten VB Namen kollidiert. Der Compiler wird's berichten ...

Im Formular wird in der DirListBox das Zielverzeichnis ausgewählt und per Open-Button die Datenbank. In der Listbox wird die Ausgabe raus geschrieben.

Die erzeugten Module fügt man dann der Anwendung hinzu und kann dann die entsprechenden Konstanten verwenden (Bsp.):

Dim rs As ADODB.Recordset 
Dim cmd As ADODB.Command 
 
Set cmd = New ADODB.Command 
 
Set cmd.ActiveConnection = CONN 
cmd.CommandType = adCmdText 
cmd.CommandText = "SELECT " & TDEF_LF_Composition_lngID & " FROM " & _ 
TDEF_LF_Composition & " WHERE " & _ 
TDEF_LF_Composition_lngComponentID & " = " & rCmp.Id 
Set rs = cmd.Execute 
' ... 

Hier noch ein Beispiel für eine Query mit Parameter:

Dim rs As ADODB.Recordset 
Dim cmd As ADODB.Command 
 
Set cmd = New ADODB.Command 
 
With cmd 
Set .ActiveConnection = CONN 
  .CommandType = adCmdStoredProc 
  .CommandText = QDEF_LF_Components 
 
  Set p = cmd.CreateParameter(QDEF_LF_Components_P_parProjectID, adInteger, adParamInput, 0, 93) 
  .Parameters.Append p 
 
  Set p = cmd.CreateParameter(QDEF_LF_Components_P_parProjectName, , adParamInput, 0, "MeinProjekt") 
  .Parameters.Append p 
End With
 
Set rs = cmd.Execute 
' ...

Da ich einige Hilfs-DLLs (ActiveX) verwende und diese nicht mitgeben möchte, habe ich die relevanten Teile in Module und Klassen kopiert. Das sieht vielleicht ein wenig wüst aus - aus zeitlichen Gründen verschönerte ich dieses jedoch nicht.

Viel Spaß und Fragen dann bitte im Forum!