Hallo,
ich nutze NPGSQL mit C#. Habe nun folgendes Problem:
Wenn ich beim NpgsqlCommand den Paramter "rder" hinzufuege, habe ich gedacht, dass dies genau so funktioniert, wie bei meinen Datenfeldern. Aber es passiert nichts. Nicht mal eine Exception wird ausgelöst!??? Warum? Oder werden Parameter in der "order by" Klausel nicht unterstützt?
GrußCode:NpgsqlCommand comm = new NpgsqlCommand( "select * from tblWort where (typ=:typ) and (utyp=:utyp) order by :order") comm.Parameters.Add(new NpgsqlParameter("order", DbType.String)); comm.Parameters["order"].Value = "typ desc";
Bubblegum
Geändert von akretschmer (21.05.2008 um 16:17 Uhr)
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
folgendes Passiert da nämlich:
natuerlich wird dieser Parameter einfach so genommen .. und auch fuer dieses ORDER BY verwendet .. was dann so ausschaut:
also ist für jede Zeile deiner Ergebnismenge der gleiche wert nach ORDER BY - also wird die Sortierung unverändert bleiben - da der gleiche Wert in jeder Reihe nie größer als der vorige oder nachfolgende ist (nochmal: weil es eben kein Feldname ist, sondern ein Wert. Du Könntest da auch beliebige Ausdrücke platzieren).Code:select ..... from .... order by 'mein-stringwert-welchen-ich-zugewiesen-habe'
Möglicherweise kann man NPGSQL aber austricksen, du solltest dir mal anschauen ob es ne Möglichkeit gib, einen solchen NPbla - parameter so zu manipulieren, dass der Wert den du uebergibst nicht quotiert in das Statement eingefügt wird. Pech hast du auf alle faelle, wenn obiges sowieso ein Prepared Statement ist, dann erledigt das Zuordnen PG selbst .. und dieses wird von nichts anderem ausgehen als einen Wert.
Grundsätzlich ist doch die SELECT-Ausführungsprozedur folgende:
prepare
execute
fetchnext
prepare kompiliert den SQL-Befehl, wozu das Festlegen des
execution-plans gehört, wobei eine Datenbank nachschaut was
es denn an bestgeeignetsten indizes gibt.
die sortierreihenfolge ist dabei eines bzw. das wichtigste
kriterium.
execute übergibt bindvars in der where-klausel an die
datenbank.
wenn nun bindvars in der "order by"-kausel ausgewertet würden,
also in tabellenspalten oder ausdrücke (z.B. 2*col1 -25)
übersetzt-gedeutet würden, könnte während des prepare-
schrittes kein passender index ausgewählt werden, weil
hier dann noch nicht bekannt wäre wonach sortiert werden soll.
daraus folgere ich, "order by :var" kann nicht funktionieren.
lösung:
vor dem prepare müssen im programm fallunterscheidungen
stehen und unterschiedliche, feste "order by"-Klauseln
entsprechend wunsch dem select-string angehängt werden.
(die umschaltung der sortierreihenfolge zur laufzeit geht nur
durch erneutes preparen.)
geert
Das hat z.B. Ausworkungen, wenn ein partieller Index verwendet wird:
In dem Fall weiss die DB nicht, ob der Wert im Index vorkommt oder nicht und kann daher den Index beim Prepare nicht verwenden. Das nicht dann nicht nur auf das Sortieren sondern auch auf die Vergleiche zu.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
er kriegt keinen Fehler - weil kein Fehler da ist ... also kein syntaktischer oder soetwas .. denn die Variable hinter dem ORDER BY ist keine Variable für einen Feld-Bezeichner, sondern für einen Wert - der dann als ODER BY Ausdruck verwendet wird. Und ORDER BY <ein Wert> ist substanzlos - diese Sortierung eruebrigt sich - er sollte einfach eine unsortierte Ergebnismenge bekommen.
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen