Hallo! > > Was spricht genau dagegen, auch die individuellen Tabellen in > der selben Datenbank zu speichern?
Mir ist nichts bekannt. Deshalb frage ich ja. > Wenn sich die globalen Tabellen �ndern darfst du halt nicht die > ganze mdb-Datei austauschen, sondern musst die �nderungen �ber > die oben beschriebenen SQL-Befehle und INSERT/DELETE ausf�hren. Klar, deshalb mache ich das ja so. Das Kernproblem sind die Views. Eine bestimmte Aufgabe kann f�r jeden Kunden individuell ausfallen. Deshalb individuelle Views und die m�glichst in einer separaten Datenbank, damit diese auch individuell gepflegt werden k�nnen. > > Mein L�sungsansatz: > > Die Datenbank auf dem Server wird geteilt: Datenbank A enth�lt die > > globalen Tabellen und Datenbank B enth�lt individuelle Tabellen, > > Verkn�pfungen zu allen Tabellen in A und alle Views/Procedures. > > Ich denke, dass eine solche Bastelei nicht sonderlich performant > ist. Bei jedem Datenbank-Befehl muss erst die Verkn�pfung aufge- > l�st und die zweite Datenbank ge�ffnet werden. Das kommt darauf an, ob bei "SELECT * FROM table IN xyz.mdb" eine zweite Databank-Engine beauftragt wird oder nicht. Wenn es nur ein JET-Modul ist, kann es dem doch egal sein, ob es auf Pages in abc.mdb oder xyz.mdb zugreift, oder? Es handelt sich ja hier nicht um ODBC-Verkn�pfungen zu beliebigen Nicht-Access-Daten. Der Verkn�pfungs-Assistent kommt also gar nicht zum Einsatz. Freundliche Gr��e Joachim van de Bruck | [aspdedatabase] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdedatabase/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdedatabase.asp
