Newsgroup: it.comp.lang.visual-basic
Titolo: [TSQL] parametri e nomi di colonne

CREATE PROCEDURE miaprocedura
(
@campo varchar(10),
@valore varchar(50) = ''
)
AS
SET @valore  =  @valore + '%'
SELECT *
FROM miatabella
WHERE @campo Like @valore
Bhe, adesso non umiliatemi, però! ;-)
Il fatto è che sono alle primissime armi con TSQL e che, con una certa
sufficienza, SQLServer non mi restituisce neanche una riga d'errore (il che
mi fornisce l'alibi per provare a capire 'dove' possa aver toppato)...così
guardo un po' più da vicino la guida e trovo:
"Per impostazione predefinita i parametri possono rappresentare solo
costanti, non nomi di tabella, nomi di colonna o nomi di altri oggetti del
database."
"D'accordo - mi dico- questo l'avevo intuito!" (in realtà penso: "Stronzo
potevi dirmelo ! grrrr!" ). Ma poi, sempre più agguerrito, comincio a
speculare su quel "Per impostazione predefinita...". Che vuol dire? che
potrei personalizzare l'impostazione (di cosa? Mah!) e riuscire a
parametrizzare anche il nome di una colonna?
Certo lo so che il mio è un capriccio tipico dei principianti, ma mi darebbe
una certa soddisfazione capire come funzioni la cosa....nel caso, anche
capire perché sia tanto stupido memorizzare una procedura di questo tipo!
grazie,
nonsonostatoio
P.S.: In alternativa potrei ricostruirmela dinamicamente da codice ed
eseguirla come una semplice query parametrica.
In tal caso, che voi sappiate, si perde molto in efficienza?
Dimenticavo: dovrebbe servire per un sitarello in ASP.
P.P.S.: Perdonate il crosspost.

 wrote in message
9l4a00$fil$1...@lacerta.tiscalinet.it...


 Andrea Montanari
Grazie per l'attenzione, Andrea.
In sostanza č quello che avrei fatto da codice VB! ;-)
Devo definirla come una Stored Procedure o altro?
Vabbč nel caso consulto la guida!...a occhio mi sembra una domanda banale,
buttata lě per pura pigrizia! ;-)
grazie.
nonsonostatoio


Ho capito! (forse)
Eseguo una Stored Procedure che esegue una....no, non è una Stored
Procedure!...
Allora eseguo una Stored Procedure, che esegue una Exec(), che esegue una
query!
Oddio! Spero non abbia controindicazioni sul piano psico-pato-logico!?! ;-S
Vabbè! formulo una 2.a domanda più interessante...forse!
Ho letto che @campo (nel mio caso) "deve essere codificato direttamente"
cioè che "non c'è modo di fornire una variabile per esso"...se non nel modo
che mi hai suggerito.
Ebbene cosa vuol dire "deve essere codificato direttamente"?
'codificare' vuol dire 'tradurre in codice'...e fin qui ci arrivo! ;-)
Quindi ipotizzo che ciò significhi che Exec() sia in grado di eseguire sia
'codice' che 'stringhe SQL', ma che non possa farlo in un'unica fase. Mah!
Ipotizzo bene?
Inoltre ho letto che il piano di esecuzione di una Exec() non viene
riutilizzato, mentre quello di una Stored Procedure si: ciò significa che
del piano di esecuzione della query 'ricostruita' dinamicamente non resta
traccia?
Se dovesse essere così, allora altro che "qualche perdita in performance"!!!
In tal senso il testo suggerisce SP_EXECUTESQL: che roba è?
è commestibile, almeno? ;-)
Scherzo!
Allora dice che è stato introdotto in SQLServer 7 e che fa ciò che fa la
Exec(), ma che prima di eseguire la query, cerca nella cache un piano di
esecuzione 'simile' a quello che dovrebbe eseguire (parametri a parte) e che
se lo trova, usa quello.
Ok! E' tutto molto bello!
Ma poi mi dice che "non posso usare un'istruzione complessa Unicode come la
concatenazione, ma che posso ricostruire la stringa Unicode e assegnarla ad
una variabile".
Che fa? mi prende per il cu...?
Ha appena finito di dire che non posso usare una istruzione di
concatenazione e mi dice che posso 'ricostruire' la stringa!?!
E come faccio? uso il Vinavil o vado di cazzuola e calcina?
Mah! Non capisco.
ringrazio in anticipo per qualunque chiarimento o confronto.
nonsonostatoio

 Ipotizzo bene?
????


 ????
Bhe, piů o meno č ciň che hai detto tu! ;)
Grazie mille Andrea.
nonsonostatoio