Hallo! > > Es ist datentechnisch logisch und geradezu zwingend > erforderlich, dass > > ein "SELECT TOP 10 ..." entweder genau 10 oder weniger oder > aber auch > > mehr als 10 Datens�tze zur�ckliefert. Ich vermute, Du > w�rdest da eine > > Fehlermeldung erwarten, wenn nicht genau 10 Datens�tze > geliefert werden, > > oder? > > Bin froh hast Du das als Spass deklariert ;)
Das war kein Scherz, das muss so sein! Stell Dir eine Rangliste vor bei denen die ersten 10 gewinnen. Zun�chst schreibst Du eine Einladung zur Siegesfeier und selektierst "SELECT TOP 10 ... ORDER BY Punkte DESC". SQL Server liefert weniger als 10 Datens�tze, wenn es weniger als 10 Teilnehmer gibt und mehr als 10 Datens�tze, wenn aufgrund der Sortierung die TOP 10 nicht eindeutig bestimmt werden k�nnen, weil z. B. die Teilnehmer auf den Positionen 8 bis 13 die gleiche Punktzahl haben. Also liefert die Datenbank trotz "SELECT TOP 10" 13 Datens�tze. W�rde es anders sein, k�nntest Du bei der �berweisung der Geldpreise auf den Positionen 8 bis 10 jemanden vorfinden, der vorher auf Platz 11 bis 13 war und deshalb gar nicht zur Siegesfeier eingeladen wurde. Es ist Sache der Anwendung, f�r eine Sortierung zu sorgen, die ein eindeutiges Ranking liefert (zus�tzliche Sortierkriterien) oder aber grunds�tzlich mehr Sieger zu akzeptieren. Die Datenbank liefert immer ein eindeutiges, nachvollziehbares und wiederholbares Ergebnis und deshalb mitunter auch mal mehr als 10 Datens�tze bei "SELECT TOP 10". Ansonsten w�re Datenintegrit�t nicht m�glich. Das ist also ein Feature, genau wie der Umstand, dass ein "UPDATE ... WHERE ..." keine Fehlermeldung erzeugt, wenn mal kein Datensatz betroffen ist. Ich denke auch, dass Dein Beispiel mit dem Bankkonto nicht trifft, weil die Anwendungslogik es halt erfordert, dass bei einer Einzahlung ein neuer Buchungssatz angelegt wird und nicht der Saldo direkt im Kontendatensatz ver�ndert wird. �hnliche Anforderungen hat auch eine Workflow-Anwendungen. Hier w�re es t�ckisch, einen Status im Auftragsdatensatz einfach nur hochzuz�hlen, anstatt die einzelnen Aktivit�ten in einer separaten Tabelle zu erfassen. Bei einem INSERT in einer Aktivit�tentabelle, bei der der Fremdschl�ssel auf die Auftragstabelle fehlt, k�me ja dann auch eine Fehlermeldung direkt von der Datenbank. Es h�ngt also von Dir ab, ob die Datenbank f�r eine logische Datenintegrit�t sorgt, am UPDATE-Verhalten liegt es ganz bestimmt nicht. > F�r mich ist SQL mit ADO eine Anwendung auf Applikationslayer, und da > erwarte ich nun mal Meldungen wenn was nicht ist wie es sein sollte. SQL Server kann aber nicht Deine Gedanken lesen. Excel liefert ja auch keine Fehlermeldung, wenn Du falsche Zahlen eintippst und Word akzeptiert es auch, wenn Du einen Brief an eine falsche Adresse schickst, ... Solche Zusatzfunktionen k�nnen von Dir aber definiert werden, wie auch ein RAISEERROR beim UPDATE auf 0 Datens�tze. Ich empfehle Dir ein Buch wie "INSIDE SQL SERVER" von Microsoft Press. Da sind die Hinterg�nde f�r solche Konstruktionen auch genau erkl�rt. Besonders die Kapitel zur referentiellen Integrit�t sind recht n�tzlich und wichtig f�r ein Datenbankdesign. Freundliche Gr��e Joachim van de Bruck ~~~~~~~~~~~~~~~~~~~~~~~~~~~sponsored by United Planet~~~~~~~~~~~~~~~~~ Intrexx.BizWalker + ODBC/OLEDB-Daten = ASP-Formular ATTACK! Download Intrexx CRM-Studio Now! http://www.intrexx.com _______________________________________________ Database.asp mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/database.asp
