Hallo Andreas!
Nur so als Gedanke:
In meinen Anwendungen speichere ich die Anwendungseinstellungen auch in einer Tabelle ab, allerdings verwende ich je Einstellung einen Datensatz und kein Datenfeld. Damit kann ich Einstellungen ergänzen, ohne den Tabellenentwurf ändern zu müssen.
Zwecks Datentyp könnte man bei Bedarf mehrere Felder mit passenden Datentypen je Datensatz verwenden und z. B. in einem weiteren Feld den Datentyp der Eigenschaft mitspeichern. Damit könnte man über die Klassen den richtigen Datentyp (in Variant eingebettet) liefern.
Deine Variante hat dafür den Vorteil, dass man die Eigenschaften als "fix" betrachten kann und somit eigentlich auch mittels Enum-Auswahl arbeiten könnte.
Bezüglich Enum:
Zur Laufzeit (mde, accde) kann man natürlich kein Enum dynamisch erzeugen - da braucht man es aber eigentlich auch nicht mehr. Man könnte aber während der Entwicklung in einem VBA-Modul ein Enum inkl. Umwandlung in einen String (z.B. über ein Array mit den Eigenschaftsnamen) bei Bedarf einfügen lassen.
Ein paar Kommentare zum Code und Code-Aufbau/Struktur:
- Code: Alles auswählen
Public Property Let OptionTable(ByVal NameofTable As String)
m_OptionTable = NameofTable
If tableExists Then
catchOptionValues
Else
m_OptionTable = ""
CancelFlag = True
MsgBox "Tabelle für Optionen nicht gefunden!"
End If
End Property
Eine Msgbox halte ich an dieser Stelle für falsch. Ich würde einen Fehler auslösen, damit der Ablauf abgebrochen wird und die aufrufende Prozedur darauf reagieren kann.
Msgboxen haben meiner Meinung nach in wiederverwendbarem Code nicht zu suchen. Die zeigt man höchsten in der obersten Fehlerbehandlungsroutine an, wo man weiß, dass kein anderer Code weiterlaufen wird.
Noch etwas: Bitte Prozedurnamen wie TabeExists groß schreiben, damit das einheitlich bleibt. (VBA/VB6 = Prozedurnamen und Parameternamen groß - egal ob public oder private - weil es leider nicht möglich ist innerhalb eine VB-Projektes unterschiedliche Schreibweisen bei Proezduren bzw. Variablen mit gleichem Namen zu verwenden.)
Bezüglich Benennung von "TabeExists": Wenn ich TabeExists lese, würde ich einen Parameter für die Übergabe eines Tabellennamens erwarten. Da das bei dir nicht der Fall ist, würde ich diese Prozedur eher "OptionTableExits" o. ä. bezeichnen. Auch wenn diese Prozedur nur in der Klasse sichtbar ist, würde ich auf die Lesbarkeit des Codes achten. (Ein "ist ja eh gekapselt" vermeidet nicht, dass der Code in der Klasse selbsterklärend sein sollte.
)
Weiters zum Überlegen:
Sind die Prozeduren "tableExists", "isPrimaryKey" usw. überhaupt zentrale Aufgabe der Klasse? - Sollte man dafür nicht eher eine andere dafür spezialisierte Klasse verwenden?
Wenn man die Datenzugriffe auslagert und die per Schnittstelle einzustellen erlaub, könnte ein Entwickler z. B. auch ADODB mit direktem Zugriff auf einen SQL-Server nutzen.
Ich weiß, viele haben am liebsten eine Klasse die alles macht und keine weitere "Hilfe" benötigt. Das führt aus meiner Erfahrung aber dazu, dass man in einer Anwendung an mehreren Stellen ähnlichen Code hat und das macht nicht zu selten ein Code-Verbesserung aufwendiger als notwendig.
... für eine komfortable Auflösung diese Abhängigkeiten habe ich den ImportWizard gestaltet.
LG
Josef
