> > [...] > > 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?
W�rde ich nicht so sehen... Standardm�ssig gibt es drei threads und die werden f�r hintergrund-aufgaben benutzt, also z.B. Caching und WriteBacks... Vermutlich wird sowieso nur ein thread f�r das abarbeiten der anfragen benutzt, also kein unterschied wegen den threads... Aber nat�rlich kann sich das insgesammt so auswirken... [..] > > > 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 Ist das wirklich das gleiche wie ein Link? Vielleicht wird bei einem Link schon beim Connection die andere Datei mit ge�ffnet und bei diesem View erst beim ansprechen des Views... Es k�nnten auch andere Caching-Mechanismen verwendet werden... Vielleicht macht das einen Unterschied.... > > 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. Sicher? Kann man den 6-fachen Connection-Aufbau nicht so interpretieren, dass man nur noch ein sechstel der Nutzer bedienen kann? Da muss wohl doch MS-Stress ran... > > 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". :-( Wieso? Es gibt doch nur eine externe Verbindung... Alles Joins lassen sich also �ber die interne zusammen mit der einen externen Verbindung l�sen... > > 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, ... > Du meinst um dem Problem zu entgehen, dass man korrupte DBs runterl�dt? Claudius | [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
