Naja, dann habe ich wohl den falschen Ansatz gehabt. Ich dachte der SENSITVE SCROLL Cursor wird gebraucht, damit er nicht die komplette Datenmenge einliest, sondern immer nur soviel liest wie er braucht. Mit STRDBG habe ich bereits gesehen welchen und dass er einen Index verwendet. Wir haben nur festgestellt das die Problemtatik überwiegend beim embedded SQL vorkommt. Ich hab das SQL über Client Access ausgeführt und er hat noch nicht mal mit der Wimper gezuckt um mir die 3 Datensätze anzuzeigen. Mit dem Sensitive Scroll Cursor 9 Minuten !!! und mit STRSQL auch noch 30 Sekunden. Ohne den Sensitive Scroll Cursor braucht er jetzt noch 30 Sekunden. @Bender ... wenn Du dir das SQL-Statement angeschaut hast, dachte ich zunächst, dass das IN das Problem ist, durch die Komplexität dahinter, lass ich das weg wirds aber auch nicht schneller. Höchstwahrscheinlich liegt es am Join auf die DNPTRNP mit mehreren Feldern gemischt. Als ich das Sensitive Cursor weggelassen hatte war dann zwar dieses SQL-Statement schneller (nur noch 30 Sekunden) was mir persönlich immer noch zu lange dauert, allerdings wenn jemand dann nur den DIST auswählt braucht er ohne Sensitive Scroll viel länger als mit Sensitive Scroll. Ich hab das jetzt so angepasst, dass er, wenn er was eingibt, bei dem ich wenig Datensätze erwarte ohne Sensitive Scroll arbeitet und wenn ich viel Datensätze erwarte mit Sensitive Scroll. Somit ist alles "erträglich" aber weit weg von zufriendenstellend.

Vielen Dank für Eure Hilfe