> > Hallo! > > > > > Ja aber woher weisst Du, dass der Datensatz nicht schon > > > vorher da war? > > > > Und lohnt es sich wirklich? Wer bl�ttert schon zur�ck? > > > > > > Wieso muss ich das wissen? Mich interessiert nur die Gesamtzahl: > > > > Um zu wissen, ob Du nur 10 oder mehr Zeilen anzeigen sollst... !? > > > > > > > > Zun�chst "SELECT TOP 10+5 ... FROM ... WHERE ... ORDER BY ..." > > > Dann if rs.RecordCount < 15 then mx = rs.RecordCount else mx = > 10 > > > For i = 1 to mx > > > Response.Write(...) > > > rs.MoveNext > > > next > > > > > > > Sorry, falls ich so drauf rumreite, abe dieser Code macht was? > > Bei allen recordcounts unter 15 bleibt es so und bei recordcount=15 > wird > > er auf 10 gesetzt!? > > Das kannst Du nicht gemeint haben - oder? > > Na! Doch!!! > > In der Regel werden 10 Datens�tze angezeigt und in Ausnahmef�llen - > erste oder letzte Seite - bis zu 15.
Ahh... Jetzt wird Licht... Ich hatte zwar das System schon verstanden, aber nicht verstanden, dass Du das Vorhandensein der 15. Zeile als Indikator daf�r nimmst, dass es noch eine n�chste Page gibt... �brigens: Die letzte Seite zeigt so nur bis zu 14(nicht 15) - oder? Woher weisst Du eigentlich wieviele Pages es gibt? Und gibt es keine Probleme, wenn zwischendurch wirklich ein Datensatz eingef�gt wird? Ich verstehe �brigens immer noch nicht, wie dieses System neu eingetragene Datens�tze erkennen soll... Daf�r m�sste man wohl das SQL sich genauer anschauen.. Claudius > > Zus�tzlich speichere ich den Sortierschl�ssel der 1. und 10. Zeile in > den Querystrings der Hyperlinks f�r das Bl�ttern oder in > Hidden-Form-Fields, damit dann die n�chste Seite auch mit "WHERE ... > > ..." aufgerufen werden kann. > > Was Dir aufst��t ist, dass ich in der Regel mehr Datens�tze aus der > Datenbank lese als ich in der Seite ausgebe. Alternativ k�nnte ich das > mit einer Stored Procedure optimieren und dann nur die ben�tigten > Datens�tze (in der Regel 10 asunahmsweise 5-15) zur�ckgeben, aber mein > Code muss auch mit Access laufen und da ist es einfacher und > performanter den Overhead zu lesen als vorab die Anzahl zu pr�fen. > > Allerdings ist mein Standard "TOP 15+5" oder "TOP 8+3". Da ist der > Overhead prozentual betrachtet nicht so gro�. ;-) > > Im �brigen ist es doch auch klar, dass man einen Preis f�r eine "etwas > intelligentere Liste" bezahlen muss. Im Dokumentensatz ist es auch > Standard, "Schusterjungen" und "Hurenkinder" zu vermeiden. > Und dann gibt > es noch etliche Anwendungen, in denen die �bliche Liste v�llig > ausreicht, z.B. wenn die Daten nicht ver�ndert werden > und/oder die Liste > so lang ist, dass eh keiner bis ans Ende bl�ttert, oder Listen f�r > Techniker ohne Sinn f�r �sthetik. ;-) > > Freundliche Gr��e > Joachim van de Bruck > > > > | [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 > | [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
