Hvis det er en forberedt erklæring, og det er en bindeværdi, der er angivet i ORDER BY klausul, det er gyldigt, MEN...
Den angivne bindeværdi vil ikke blive fortolket som SQL-tekst. Det vil sige, at værdien kun ses som en værdi (som en bogstavelig streng). Det vil ikke blive set som et kolonnenavn eller en ASC eller DESC søgeord.
I forbindelse med din erklæring skal du angive en værdi for :orderClause bind pladsholder, det vil have samme effekt, som hvis du havde skrevet ORDER BY 'some literal' .
Og det er slet ikke en bestilling af rækkerne.
(Dette gælder i det mindste i hvert SQL-klientbibliotek, jeg har brugt med DB2, Teradata, Oracle, SQL Server, MySQL og MariaDB (JDBC, Perl DBI, ODBC, Pro/C, et al.)
(MyBatis giver en praktisk mekanisme til at udføre variabel substitution i SQL-teksten, dynamisk ændring af SQL-teksten, før den er forberedt, men disse substitutioner håndteres FØR sætningen forberedes og bliver ikke til bindepladsholdere i sætningen.)
Det er muligt at få et minimum af "dynamisk" rækkefølge med nogle omhyggeligt udformede udtryk i ORDER BY-klausulen. For eksempel kan vi have vores statiske SQL-tekst til at være sådan her:
ORDER BY CASE WHEN :sort_param = 'name ASC' THEN activation_name END ASC
, CASE WHEN :sort_param = 'name DESC' THEN activation_name END DESC
(SQL-teksten her er ikke dynamisk, den er faktisk statisk, det er, som om vi havde skrevet.
ORDER BY expr1 ASC
, expr1 DESC
"Tricket" er, at udtrykkene i ORDER BY-sætningen betinget returnerer enten værdien af en kolonne fra hver række, eller de returnerer en bogstavelig (i eksemplet ovenfor, den bogstavelige NULL), afhængigt af værdien af en bind værdi, evalueret på udførelsestidspunktet.
Nettoeffekten er, at vi "dynamisk" kan få effekten af enten:
ORDER BY activation_name ASC, NULL DESC
eller
ORDER BY NULL ASC, activation_name DESC
eller
ORDER BY NULL ASC, NULL DESC
afhængigt af hvilken værdi vi leverer til :sort_param pladsholderen.