Hallo!

> Zur Sortierung!
> 
> Haste mal versucht ein Order By in einer SQL Stored Procedure 
> dynamisch
> zu setzen?

Ja. ;-)

> CREATE PROC USERLISTE
> @Sort AS VARCHAR(100)
> 
> AS
> SELECT Name, Vorname FROM User ORDER BY @Sort
> 
> Leider geht das ebend nicht!

MS sei Dank werden SPs vorkompiliert, die "sp�te Namensaufl�sung"
funktioniert also nicht.

> Ausweg: 
> 
> Beispiel:
> 
> CREATE PROC USERLISTE
> @order AS nvarchar(50)
> 
> AS
> 
> SELECT  *
> FROM dbo.KB_objects
> ORDER BY  CASE @order WHEN 'Name'                     THEN Name ELSE
> NULL END,
>               CASE @order WHEN 'Vorname'              THEN Vorname
> ELSE NULL END DESC,
>               CASE @order WHEN 'label'                THEN label ELSE
> NULL END DESC,
> 
> Usw.

Warum so kompliziert?

CREATE PROCEDURE Userliste
   @Order VARCHAR(200)
AS
   EXECUTE 'SELECT * FROM KB_objects ORDER BY ' + @Order

... reicht doch aus. Und die sp�te Namensaufl�sung wird auch deutlich.

> Wie Du siehst geht das �ber Diesen Umweg! Wenn Du aber jetzt auch noch
> anfangen willst - Zeilen Kombiniert zu sortieren dann wird das noch
> aufwendiger!

Nein, daf�r gibt es Views/Stored Procedures. Komplexe Abfragen �ber mehrere
Tabellen erledigt man am besten �ber mehrere Views, so dass jede einzelne
View parametrisiert und vorkompiliert werden kann. Erst die letzte View
erh�lt dann die ORDER-BY-Klausel, ggf. mit "sp�ter Namensaufl�sung". Also z.
B. mehrere Views mit JOIN, eine View mit UNION und dann mehrere Views f�r
verschiedene ORDER BY- Klauseln. Letzteres kann - bei kleinen Datenmengen -
entfallen und  im DataSet durchgef�hrt werden.

> Da ist es doch wesentlich einfacher die Daten gleich im DataSet (�ber
> DataView) zu sortieren - zumal Du dann immer nur einen Select 
> Anweisung
> brauchst!
>
> Weil - einfache Select Anweisung funktionieren auf dem SQLServer, auf
> MySQL, auf Access, auf Oracle usw. immer gleich!

... ich kann mir durchaus einige F�lle vorstellen, wo das nicht zwingend der
Fall ist ;-) ...

> Und da dann auch der DataView gleich ist - sinkt der
> Implementierungsaufwand auch! Sicher sind Stored Procs. Schneller als
> einfache SQL Anweisungen - aber dann mu� man abw�gen - was einem
> wichtiger ist!

F�r SQL Server, Oracle oder Access lassen sich einheitliche Datenzugriffe
durchaus realisieren. MySQL f�llt nat�rlich aus dem Rahmen, weil es keine
echte Datenbank ist, bzw. weil dort wichtige Funktionen f�r die
Datenintegrit�t einfach immer noch fehlen (Transaktionen, Trigger, Views,
...).

> Was ich haupts�chlich meinte ist das man per DataSet oder wie 
> auch immer
> die DB eigentlich nur einmal abfragen mu� - und dann kann der User die
> n�chsten Tausend Sortierungen direkt auf den 1x gelieferten Daten
> ausf�hren!

Das trifft ganz sicher f�r eine Bildschirmseite mit Daten zu, die dann per
Mausklick nach beliebigen Spalten sortiert wird. Allerdings sind
Sortierungen h�ufig komplexer, also kombinierte Spalten oder eigene
Collations oder Schl�sselfelder, die nach einem numerischen Wert und nicht
nach dem angezeigten Text sortiert werden m�ssen. Deshalb verzichte ich in
der Regel auf die Sortierung per Klick auf den Spaltennamen und biete
stattdessen f�r die Sortierung eine extra Zeile oder eine DropDownliste an.
Und in der Tat sortiere ich dann auch schon h�ufiger direkt im DataSet, es
sei denn die Sortierung ist f�r die Selektion wichtig (SELECT TOP ...). Auf
keinen Fall w�rde ich jedoch eine gro�e Tabelle komplett in das DataSet
laden, das funktioniert dann zwar gut auf dem Entwicklungsserver, jedoch
nicht mehr auf dem Produktionsserver, wenn dort Hunderte oder gar Tausende
auf die Seiten zugreifen.

> Ob man das will - kommt haupts�chlich auf die Daten und Ihre 
> Fluktuation
> an - quasi wie h�ufig �ndern sie sich - und sind die �nderungen so
> relevant - das ich sie sofort sehen will - oder reicht es mir wenn ich
> aller x Min / x Tage frische Daten habe! Eine Sitestatistik reicht ja
> quasi wenn Sie jeden Tag bzw. jeden Monat aktualisiert wird! Ein
> B�rsenticker sollte die �nderungen dagegen sofort zeigen!

Freundliche Gr��e
Joachim van de Bruck

_______________________________________________
Asp.net mailing list
[EMAIL PROTECTED]
http://www.glengamoi.com/mailman/listinfo/asp.net

Antwort per Email an