Hallo! > Hier ist was ich in der MSDN-Lib gefunden habe: > > [...] > The disadvantages are: > Access ignores referential integrity between local and remote tables. > Fortunately, Access enforces any referential integrity constraints you > have established between individual tables in the remote database. > [...] > Hieraus schliesse ich, dass Indices benutzt werden, denn ref.Integr. > innerhalb der remote DB zu handeln ohne Indices zu benutzen w�re so > unglaublich langsam, dass das an dieser Stelle bestimmt erw�hnt worden > w�re...
Stimmt. > [...] > ADO and ADOX distinguish between tables that are linked from native > Access database tables and installable ISAMs, and those linked by using > ODBC drivers. If you use the ADO OpenSchema method and specify > adSchemaTables as the QueryType argument to return a Recordset object > that describes a database's tables, the TABLE_TYPE field returns "LINK" > for linked Access tables and linked installable ISAM tables. However, it > returns "PASS-THROUGH" for tables linked by using ODBC drivers. This is > also true for the ADOX Table object's Type property. This is equivalent > to using the DAO Attributes property with the read-only dbAttachedTable > and adAttachedODBC constants. > [...] > Aus dem hier und noch einem anderen Artikel, der erw�hnt, dass die > Jet-Engine verschiedene Threads benutzt und das man diese erh�hen > soll(Registry), wenn man viele gelinkte Tabellen hat schliesse ich, dass > die Jet-Engine bei gelinkten Access-DBs bzw. Durch ISAMs erreichbare > Daten keine zus�tzliche Jet-Engine bem�ht, sondern das intern mit > eigenen Threads regelt, wobei es aber nicht so ist, dass ein Thread fest > einer DB zugeordnet wird. Stimmt leider, was wohl bedeutet, dass man weniger Benutzer gleichzeitig bedienen kann, oder? > [...] > You can use a linked table just like you would use any other table in > your Microsoft Access database. For example, you can create forms, > reports, and queries that use the external table. Keep in mind that > performance may be slightly slower with linked tables than with regular > Microsoft Access tables due to time spent connecting to and retrieving > external data. > [...] > > Ein wenig speicher- und zugriffs-overhead, weil zus�tzliche dateien > offen gehalten werden m�ssen mit entsprechenden cache-Strukturen und > entschieden werden muss auf welche Dateien bestimmte Anfragen gehen... Nach meinen Beobachtungen entsteht der Overhead im FileSystem, h�lt sich also in bescheidenen Grenzen. > > Poste bitte hier, wenn Du mehr rausfindest. Ich hab jetzt beide Varianten einmal getestet, allerdings noch ohne MS-Stress. Testverlauf: 1. 10.000 Datens�tze eingef�gt (10.000 INSERT-Statements) 2. 10.000 Datens�tze sortiert gelesen (1 SELECT-Statement) 3. 10.000 Datens�tze per Index gelesen (10.000 SELECT-Statements) 4. 10.000 Datens�tze gel�scht (1 DELETE Statement) Die zweite Datenbank enth�lt nur eine View: SELECT * FROM test IN datenbank.mdb Ergebnis: Entscheidend ist nur die Zeit, die f�r den Aufbau der Verbindung ben�tigt wird. Der Unterschied in den F�llen, wo ein einzelnes INSERT- oder SELECT- oder DELETE-Statement ausgef�hrt wird, ist in VBScript nicht messbar. Nur wenn man mehrere Statements hintereinander ausf�hrt gibt es messbare Unterschiede, wobei die Verkn�pfungen etwa 2 bis 6 mal mehr Zeit ben�tigen. F�r die Praxis ergeben sich also keine messbaren Performance-Einbu�en. Es gibt aber einen gravierenden "Nachteil": Pro SQL-Statement darf es nur eine externe Verbindung geben. Ganz normale JOINS m�ssten also in der Originaldatenbank erstellt werden. Also Essig mit "alle Views/Procedures in einer separaten Datenbank". :-( Wenn man aber z. B. Datenbanken bei einem Provider abgleichen will, kann man das sehr wohl mit verkn�pften Tabellen machen, also z. B. alle neuen Daten in eine separate Datenbank kopieren, diese downloaden, verarbeiten, wieder uploaden, ... 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
