Markus Walber wrote:
> Nein, keine StoredProcedures.
> Simple Abfragen per OLE-DB.
> Sehr viele verschiedene Abfragen. Ich suche ja gerade die, die mir
> Probleme macht.
> Sehen alle etwa so aus:
>
> select x,y,z from Artikel where benutzer=4711 and irgendwas='bla'
>
> Teilweise werden auch Updates und Inserts �ber ADO gemacht.
> (
> rs("wert") = "neu"
> rs.update
> )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. > Ich weis, dass es mit StoredProcedures u.U. Schneller gehen k�nnte. > W�sste ich nun welche > Abfragen die Leistungseinbr�che verursachen, k�nnte ich an dieser > Stelle Umbauen. > Wollte ich alles sofort umbauen, waere ich Jahre besch�ftigt. 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 Weiterhin: Schau Dir mal mit sp_lock die aktiven Sperren an, die von den Statements erzeugt werden. Ist im ersten Moment aussagekr�ftiger, als der Profiler. Gruss Frank _______________________________________________ Database.asp mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/database.asp
