Verweis auf accde - kein Zugriff auf übergeordnete Formulare

[coly]

Hallo,

Ich habe eine Access Anwendung bei mehreren Kunden mit derselben Benutzeroberfläche, aber mit unterschiedlicher Konfiguration laufen. Die gesamte Anwendung ist jeweils in einer einzelnen Access Datenbank, was eine Wartung und Weiterentwicklung sehr schwierig macht.

Jetzt möchte ich Anwendungs- und Geschäftslogik trennen sodass bei einem Update lediglich eine Datei ausgetauscht werden muss ohne dass sich dabei die Geschäftslogik ändert oder angepasst werden muss.

Dazu habe ich eine accde erstellt, die lediglich ein Hauptformular, allgemeine Klassen sowie Module mit öffentlichen Funktionen enthält. Über das Hauptformular sollen dann zur Laufzeit beliebige Unterformulare eingebunden werden. Diese Unterformulare beinhalten die Geschäftslogik und sollen in einer separaten Access Datenbank abgespeichert werden, die wiederum auf die accde verweist.

Und genau hier liegt mein Problem. Ich schaff es nicht in meinem Hauptformular, das in der accde liegt, auf Formulare in der accdb zuzugreifen bzw. als Unterformular einzubinden. Konkret geht's hier um SourceObject im Unterformular und um die Formulare selber. Im Hauptformular werden immer nur Objecte der accde referenziert, was ja im Grunde auch logisch ist. Selbiges Problem hab ich mit der RecordSource eines Formulars, das könnte ich allerdings teilweise mit currentDB umgehen, weil hier immer auf die Tabellen der gestarteten Anwendung verwiesen wird.

Würd ich das Hauptformular auch in die accdb geben und nur den Quellcode in der accde lassen, würde mein System wieder funktionieren. Allerdings bin ich dann wieder in der Weiterentwicklung gehemmt, weil ich Anwendungslogik und Geschäftslogik wieder teilweise vermischt habe.

Vielleicht hat ja jemand einen Tipp für mich.

gruß coly

[database]

Hallo,

die Aufteilung einer Datenbank erfolgt in der Regel in EIN Frontend und EIN (u.U. mehrere) Backend(s), wobei im FE alle DB-Objekte ausser den gemeinsam genutzten Tabellen zu liegen kommen.

"Jetzt möchte ich Anwendungs- und Geschäftslogik trennen ..."

Anwendungs- und Geschäftslogik sind in manigfaltiger Weise miteinander verbunden - es ist in der Regel ja so, dass die Steuerung von Formularen (Anwendungslogik)
zu dem Zweck geschaffen wird um dem Benutzer ein komfortables Arbeiten mit den Geschäftsdaten zu ermöglichen.

Dass ein Zugriff auf Datenbankobjekte in der von dir beschriebenen Form realisierbar ist ist mir neu, d.h. mir ist nicht bekannt,
dass von einer geöffneteten Datei aus ein Formular einer geschlossenen Datei geöffnet werden kann um damit zu arbeiten.

"Ich schaff es nicht in meinem Hauptformular, das in der accde liegt, auf Formulare in der accdb zuzugreifen bzw. als Unterformular einzubinden..."

Du kannst keine Formulare einer fremden Datei 'einbinden' das gelingt m.W. ausschließlich mit Tabellen.

"Würd ich das Hauptformular auch in die accdb geben und nur den Quellcode in der accde lassen, würde mein System wieder funktionieren..."

Was ich schwer in Frage stellen möchte ... eine Fehlerquelle ohnegleichen
Für mich macht so ein Gewürge keinen Sinn und erschwert die Arbeit für dich eher als dass es dir hilft.

Ich würde mich da eher in die Richtung bewegen eine ganz 'normale' Aufteilung der DB zu realisieren
und die Objekte des FE so zu organisieren, dass sie überschaubar gewartet, erweitert und upgedatet werden können.
Jede andere Überlegung fürht m.E. zu Fehlerquellen und damit verbunden zu Funktionsstörungen größeren Umfangs.
Bei der Weitergabe der Projekte würde ich persönlich von *.accdb - Dateien generell Abstand nehmen!  

HTH

[coly]

Hallo Peter!

Genau das, was du vorschlägst , mach ich seit Jahren und kann meine Projekte genau aus diesem Grund nicht mehr vernünftig  Verwalten, da ich jede Änderung der Anwendungslogik in jedem Projekt manuell nachbessern muss was wiederum äußerst Fehleranfällig ist weil einfach die Übersicht verloren geht wenn die Projekte größer werden. Geschweige denn davon, dass ich dem Kunden nicht einfach eine Datei geben kann um das System upzudaten sondern jedes Mal selber Hand anlegen muss. Von Prinzip her ist es nichts anderes als wie eine DLL auszutauschen, nur in diesem Fall halt eine kompilierte Access Datei. Ich möchte Anpassungen am System, die nicht kundenspezifisch sind, künftig nur mehr einmal machen und nicht mehr bei jedem Kunden separat.

Warum ein Verweis ein Gewürge sein soll, kann ich nicht nachvollziehen. Das hier ist ja nur ein Teil meines Konzeptes, darum scheint das eine oder andere möglicherweise etwas verwirrend und ohne Verweis würde Access erst gar nicht funktionieren.

Wenn du in einer Access Datenbank einen Verweis auf eine andere, beliebige Access Datenbank machst, kannst du dort auf alle öffentliche Funktionen und Variablen zugreifen und somit auch ein dort enthaltenes Formular starten. Es muss lediglich der Projektname geändert werden, da es sonst zu einem Namenskonflikt kommt. http://msdn.microsoft.com/en-us/library/aa210706(v=office.11).aspx

Ich bin auch nicht auf ein Backend Datenbank beschränkt, ich binde mssql,  mysql  genauso wie SharePoint oder bei kleinen Installationen einfach eine andere Access Datenbank, je nachdem wo der Kunde halt seine Daten gespeichert hat und egal ob in einer oder mehreren Datenquellen. Das ist ja genau einer der Hauptpunkte meiner Anwendung, ein Fronted für verteilte Datenquellen in dem sehr schnell und effizient nach Informationen gesucht werden kann. Jetzt soll die Weiterentwicklung auch mal effizient werden 

[database]

Hi,

"...  kannst du dort auf alle öffentliche Funktionen und Variablen zugreifen und somit auch ein dort enthaltenes Formular starten ..."

VBA - OK, das ist mir sehr wohl bekannt - von Formular starten habe ich auf den Seiten des Herstellers nichts gelesen.