2009-07-09 3 views
0

Ich versuche, eine Datenbank in zwei Teile zu teilen - ein Backend, das automatisch aktualisiert wird, und ein Frontend, das das Suchen und Hinzufügen/Bearbeiten von Kommentaren ermöglicht. Die Daten in der Quelldatenbank werden aus mehreren Tabellen in ein Paar von Abfragen zusammengeführt, und ich möchte diese Abfragen als Quelle der aktuellen Datenbank verwenden.Wie Verwenden einer Abfrage in einem anderen DB als RecordSource eines Formulars?

Access 2007 unterstützt die Aufteilung einer Datenbank in mehrere Teile, aber nicht in der Art, die ich suche. Er behält die Tabellen in der Quelldatenbank und fügt alle Formulare, Abfragen, Berichte und Makros in die neue Datenbank ein. Die Tabellen und Abfragen befinden sich bereits im Back-End, und diese neue Datenbank sollte dem Endbenutzer nur eine gute GUI bieten.

Access 2007 unterstützt auch verknüpfte Tabellen, die jedoch nur eine Tabelle als Quelle und kein Abfrageobjekt verwenden können.

Ich dachte, dass der beste Weg, dies zu tun wäre, um eine SQL-Abfrage zu tun, nach dem Vorbild der

SELECT * FROM SourceQuery IN "C:\Path\To\ExternalDB.accdb"; 

Ist das, was zu noch möglich arbeite ich, und wäre dies der beste Weg sein, TU es?

Da es immer noch relativ früh im Projekt ist, ist die Neustrukturierung der Datenbank nicht ausgeschlossen, aber etwas, das ich lieber vermeiden würde.

+0

Warum sind Sie dagegen, dass die Abfragen, wo sie hingehören, im Frontend liegen? –

Antwort

1

Sie haben die übliche Access BE-FE-Division richtig beschrieben: nur Tabellen im Backend. Ich bin mir bewusst, dass nicht alle DB-Programme dies tun, aber dies ist Access und mein Ansatz wäre, die übliche Aufteilung zu beachten. (Und Sie haben kaum eine Wahl, dass Sie nicht in Access eine "Verbindung zu einer Abfrage" herstellen können.)

Überprüfen Sie Ihren Kommentar ("Es gibt einen bestimmten Grund ..."), ich denke, das würde möglicherweise

bedeuten
  • Hinzufügen von ein paar mehr Tabellen zum Back-End, im Wesentlichen Eimer (Import-Daten in der fertigen Form; Export 1; Export 2), die alle Benutzer zu konsistent verarbeiteten Daten zu bekommen;
  • macht eine kleine Admin FE, die neben dem BE sitzt und speichert Ihre Module, Abfragen für den Export und Exportroutinen; und
  • mit einigen redundanten Abfragen auf dem Benutzer FE. Das ist ärgerlich in meiner eigenen Arbeit. Ich versuche nur, stabile stabile "Baustein" -Abfragen in diesen Rollen zu entwerfen, und halte ihre Anzahl auf ein Minimum.
  • +0

    Bei Überprüfung, denke ich, Ideen 1 und 3 sind wahrscheinlich überflüssig. Sie müssten ENTWEDER einige Bucket-Tabellen erstellen oder Abfragen für die Benutzer-FE haben, die das BE widerspiegeln. Ich benutze manchmal # 1 und # 2 - hängt von der jeweiligen Funktion ab. – Smandoli

    1

    Ich hoffe, ich verstehe Sie richtig, aber die sinnvollste Lösung wäre, die Tabellen in der Back-End-DB zu verknüpfen und die Abfragen in die UI-Datenbank zu kopieren. Diese Abfragen wären weiterhin in der Lage, ohne Probleme auf die Tabellen für den Tabellenzugriff (über die verknüpften Tabellen) zuzugreifen und auf normale Weise auf Ihre Formulare und den VBA-Code zuzugreifen.

    Gibt es einen bestimmten Grund, warum Sie die Abfragen in der UI-Datenbank nicht möchten?

    +0

    Es gibt einen bestimmten Grund, die Abfragen im Backend zu behalten: Es gibt einige Codemodule: eines, das einen Datenblock für den Import vorbereitet, und eines, das die Ergebnisse eines Abfragepaars in Tabellenkalkulationen exportiert. Da sich das Backend auf einem Server befindet und das Ziel darin besteht, nur die Benutzeroberfläche an die Benutzer zu verteilen, bin ich nicht sicher, wo diese Codemodule nach der Aufteilung landen werden. –

    +2

    Abfragen im Backend, die von UDFs in Codemodulen im Backend abhängig sind, können von den Clients nicht ausgeführt werden, es sei denn, Sie haben einen Verweis auf das Back-End mit dem darin enthaltenen Code.Hören Sie auf, mit Access zu kämpfen und Ihre Anwendung so zu gestalten, wie Access entworfen wurde, mit allem außer den Datentabellen im Frontend. –

    +0

    David hat Recht. Wenn Sie feststellen, dass Sie gegen die Plattform kämpfen, tun Sie wahrscheinlich falsch. Wenn Sie Code (und Abfragen zählen als Code, nicht Daten) im Back-End, dann ist es nicht mehr ein Back-End. – JohnFx

    Verwandte Themen