> > Hallo! > > > > 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.... > > Sehr wahrscheinlich. Auf jeden Fall wird die Verbindung zum Back-End > erst mit der View aufgebaut, also immer wieder neu. Eine st�ndige > Verkn�pfung wie zwischen Front-End und Back-End normalerweise �blich, > kann ich im Web nicht verwenden, da weder VBA noch der > Verkn�pfungsmanager gestartet werden k�nnen. Vielleicht gibt > es da noch > was im Connection-String. Das muss ich noch pr�fen.
Versteh ich nicht, wieso das nicht gehen soll... Kann man nicht mit ADOX Table-Links anlegen, die auf die richtige Datei zeigen? > > > > 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... > > Ja, und dann kommt's wieder auf das Connection-Pooling an. Echte > Performance-Messung geht halt nur mit MS-Stress. > > > > 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... > > Steht so auch in der MSDN. Ich habe zwei Views nach dem > Standard-Muster > "SELECT * FROM ... IN ...". Wenn ich jetzt diese beiden Views mit JOIN > verkn�pfe gibt es einfach einen Syntax-Error. Laut > Dokumentation max. 1 > "FROM ... IN ..." pro Statement. Dabei hatte mein Statement selber > �berhaupt kein "FROM ... IN ...". ;-) Aber mit echten Links w�rde es gehen !? (Siehe oben) Claudius > > > > 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? > > Grunds�tzlich ist es bl�d, wenn man die Datenbank komplett > herunterladen > muss, um �nderungen vorzunehmen oder diese Daten in anderen > Anwendungen > zu verwursteln. Einerseits st�ren bei gro�en Datenmengen die Down- und > Uploadzeiten, andererseits kann man die Datenbank nicht mehr einfach > wieder uploaden, ohne die �nderungen, die in der Zwischenzeit erfolgt > sind, platt zu machen. Wenn so etwas laufend erforderlich > ist, nehme ich > von vornherein den SQL Server, weil ich mich einfach dagegen wehre, > solche "simplen" Tools selber zu entwickeln. Bei SQL-Server im Web > reicht ein simples MSI- oder SQL-Script, um �nderungen in der > Datenstruktur oder in den Daten vorzunehmen. > | [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
