Hallo! > Hallo Markus, > > erst einmal was zu den "Indexen". > Ein SQL-Statement wird von hinten nach vorne gelesen. Daher > legt man Indexe > auch auf die Spalten, die in der WHERE-Clause verwendet > werden. Dabei sollte > man ber�cksichtigen, dass Indexe die Schreibgeschwindigkeit senken.
Ja, aber wenn die Abfrage bei wenigen Benutzern nur 10 ms ben�tigt, liegt es ganz bestimmt nicht an den Indexen, oder? > Ich w�rde mir zuallerst die Update-Statements anschauen. > Insert ist nicht > ganz so kritisch. > Diese Statements solltest Du durch die eine oder andere > StoredProcedure > ersetzen (was schon mal einen Schub bringen wird) > Wenn Du einen benutzerdefinierten Index angelegt hast, kannst Du per > sp_indexoptions die Zeilen- bzw. Tabellensperre ab-/einschalten Das erkl�rt aber nicht die "Performance-Steigerung". Wenn Abfragen, die sonst 10 ms dauern, bei steigenden Benutzerzahlen dann bis zu 5600 ms ben�tigen, riecht das eher nach einem Lizenzproblem, zumal ja "nur" mit ADO und nicht mit komplexen Stored Procedures zugegriffen wird. Oder aber: Du verwendest ClientSide-Keyset- oder -Dynamic-Cursor? Die haben in Web-Applikationen nichts zu suchen. In Web-Applikationen brauchst Du auch kein Locking, h�chstens Logical-Record-Locking, aber jeder Benutzer bearbeitet ja nur seine Daten, oder? Was musst Du also locken? Nimm also f�r die Abfragen jeweils einen ClientSide-Firehose-Cursor und f�r die Modifikationen parametrisierte ADO-Commands (CommandText oder Stored Procedure) und Du kannst mehrere 1.000 Benutzer bedienen. Zus�tzlich achte darauf, dass alle Objekte so sp�t wie m�glich ge�ffnet und dann so schnell wie m�glich wieder geschlossen werden, damit das Connection-Pooling auch funktioniert. Freundliche Gr��e Joachim van de Bruck _______________________________________________ Database.asp mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/database.asp
