OOP mit Access VBA

[Marcus Maschler]

Hallo miteinander,

ich beschäftige mich seit geraumer Zeit mit der Erstellung einer kleinen Access-Anwendung. Ich versuche dabei, einen OO Ansatz
zu realisieren.

Jetzt suche ich nach einer möglichst allgemein nutzbaren Möglichkeit, meine selbstdefinierten Klassen / Objekte aus den jeweils zutreffenden Tabellen zu laden und sie später auch wieder entsprechend zu speichern (Persistenz). Wichtig dabei ist auch die Möglichkeit, die SQL-Statements, die beim Laden zur Anwendung kommen, möglichst dynamisch dahingehend anpassen zu können, daß - bei Bedarf - auch WHERE-Klauseln berücksicht werden, sodaß ich z.B. Collections nur mit einem Teil der in den jeweiligen Tabellen enthaltenen Daten befüllen kann.

Am liebsten würde ich sämtlich SQL-Anweisungen in einer eigenen Hilfsklasse kapseln, die dann die Daten für die anderen
(Collection-)Klassen zur weiteren Verwendung im Rahmen der Anwednung zur Verfügung stellt.

Kann mir jemand weiterhelfen?

[Bernhard Geyer]

Vergiss Access VBA.
Wenn Du richtig OO-Programmiren willst nimm auch 'ne richtige Programmiersprache wie Delphi, Java, C# oder auch VB.<b>NET</b>. Zugriff auf eine Access-Datenbank ist hier kein Problem.

Access VBA ist mehr für schnell "hingefriggle" gedacht als für größere Anwendungen. Du wirst viel zu schnell an vielen Stellen Probleme mit dem VBA-Konzept von Access bekommen

[Marcus Maschler]

Hallo,

danke für die Antwort. Grundsätzlich kann ich da auch nur zustimmen. Ich würde auch lieber mit Java oder C# arbeiten,
muss allerdings VBA benutzen, da ich etwas anderes nicht ohne weiteres in den Betrieb einführen kann. Daher ist es das einfachste für mich, eine simple Accessdatei bereitzustellen.

Habe gestern auch bereits mal im Internet nachgeschaut und bin jetzt zumindest so schlau, daß ich weiß, daß es sich bei der Überwindung des Bruches zwischen OO und RDBMS um ein grundsätzliches Problem handelt. Muss aber dennoch irgendeine Lösung finden..

[Bernhard Geyer]

> muss allerdings VBA benutzen,

Wer hatt den so eine besch... Regel aufgestellt. Es ist vergebliche Liebesmühe. Wir haben selbst ein größeres Programm basierend auf Access von einem Fremdhersteller laufen und ich glaube der Hersteller (kleinere Firma) verflucht sich immer wieder wieso bei einer frühere Entscheidung Access als Entwicklungsbasis genommen wurde