Controllo Sintassi SQL
Pierluigi Terzoli
sapete se č possibile effettuare un controllo sintattico di uno statement
SQL immesso in una test box ??
Grazie, Pierluigi.
Ernest Morariu
No, credo non sia possibile. La sola soluzione è eseguirlo e gestire le
eccezioni.
ernest
"Pierluigi Terzoli" <pierluig...@hotmail.com> wrote in message
news:#486E1Yk...@TK2MSFTNGP12.phx.gbl...
> Salve a tutti,
> sapete se è possibile effettuare un controllo sintattico di uno statement
Pierluigi Terzoli
temevo la tua risposta (nel senso della non esistenza di un metodo apposito
;).
Infatti, sto cercando di implementarne uno.
Praticamente, gestisco una transazione sulla quale eseguo i comandi SQL e
della quale non faccio mai la commit.
In funzione delle eccezioni dedico la validità della sintassi.
Ora la provo.
Devo ringraziarti Ernest, sei sempre molto preciso e tempestivo.
Grazie ancora, P.
"Ernest Morariu" <REMOVEM...@gesora.com> ha scritto nel messaggio
news:ufGjgAZk...@TK2MSFTNGP09.phx.gbl...
Mauro Servienti
Pierluigi Terzoli wrote:
> Ciao Ernest,
> temevo la tua risposta (nel senso della non esistenza di un metodo
> apposito ;).
A prima vista sembrerebbe proprio di no, ma se guardi il QueryAnalyzer di
SQL un comando per eseguire il Parse dello statement prima dell'esecuzione
effettiva esiste, e questo non fa altro che controllare la validità
sintattica dell'espressione.
Farei un tentativo sul NG microsoft.public.it.sql perchè è probabile che
esista un sp di sistema non documentata che permetta queste operazioni
Ciao
Mauro
Alex
SqlServer
http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&threadm=uazZ4kyJEHA.428%40TK2MSFTNGP11.phx.gbl&rnum=8&prev=/groups%3Fhl%3Dit%26lr%3D%26ie%3DUTF-8%26q%3Dsqldmo%252Bparser%252Bsql
------------------------------------------------------------------------
If you're willing to take a round-trip to the server it's not too bad. Just
execute:
SET PARSEONLY ON
before your statement, and then execute the statement on the same
connection. While this is on, sql server will only check the syntax of
statements on that connection, and not compile or execute them.
-----------------------------------------------------------------------
praticamente un'aggiunta alla soluzione che credo tu stia implementado
che ti evita la transazione e dovrebbe essere più performante
--
HTH
--
Alex
UGIdotNET - http://www.ugidotnet.org
Weblog: http://www.ugidotnet.org/2435.blog
Ernest Morariu
> SQL un comando per eseguire il Parse dello statement prima dell'esecuzione
> effettiva esiste, e questo non fa altro che controllare la validità
> sintattica dell'espressione.
Mauro,
Io pensavo che Pierluigi volesse fare questa verifica sul lato client per
risparmiare una strada verso il server.
Chiamare una sp sul lato server che fa la verifica della sintassi oppure
eseguire direttamente il comando sql , sinceramente, non vedo che
differenza fa. Il risultato è sempre lo stesso.
ernest
"Mauro Servienti" <maurose...@online.nospam> wrote in message
news:Oky4zPZk...@TK2MSFTNGP11.phx.gbl...
Pierluigi Terzoli
in effetti sto tenendo d'occhio su Microsoft.public.dotnet.framework.adonet
se qualcuno ha una risposta ad un post di un certo WF di ieri che chiedeva
la stessa cosa.
Ciò che tu mi dici è probabile.
Anche perché a me piacerebbe un controllo formale dello statement SQL
indipendentemente dal fatto di trovare riscontro nel DB sottostante.
Comunque, la funzione che ho predisposto sembra funzionare.
P.
"Mauro Servienti" <maurose...@online.nospam> ha scritto nel messaggio
news:Oky4zPZk...@TK2MSFTNGP11.phx.gbl...
Mauro Servienti
>> A prima vista sembrerebbe proprio di no, ma se guardi il
>> QueryAnalyzer di SQL un comando per eseguire il Parse dello
>> statement prima dell'esecuzione effettiva esiste, e questo non fa
>> altro che controllare la validità sintattica dell'espressione.
>
> Mauro,
>
> Io pensavo che Pierluigi volesse fare questa verifica sul lato
> client per risparmiare una strada verso il server.
> Chiamare una sp sul lato server che fa la verifica della sintassi
> oppure eseguire direttamente il comando sql , sinceramente, non vedo
> che differenza fa. Il risultato è sempre lo stesso.
Certo,
ma questo lo fa già se simula una transazione senza effettuarne il commit.
L'unica soluzione sarebbe quella di costruirsi un parser da zero, ma mi
sembra quantomeno un lavoro megalitico.
>
> ernest
Ciao
Mauro
Pierluigi Terzoli
l'esportazione di dati dal DB verso un file di testo.
Quindi, gli permetto di dichiarare una select che poi salvo sul DB per poi
essere eseguita in un secondo momento.
Siccome prevede anche l'importazione è quindi possibile specificare anche
degli statement di Insert/Update.
Quindi, non devo eseguire gli statement ma solo verificarne la correttezza.
P.
"Ernest Morariu" <REMOVEM...@gesora.com> ha scritto nel messaggio
news:eGl8AXZ...@tk2msftngp13.phx.gbl...
Ernest Morariu
non riesco a capire il collegamento fra la transazione e la sintassi. Se un
comando sql ha *errori di sintassi* non viene proprio eseguito.
Sono i comandi che contengono errori di logica(non di sintassi) che possono
essere parzialmente eseguiti, quindi che richiedono la presenza di una
transazione se non si vuole fare una "mezza" modifica.
Gli errori di logica credo siano verificabili solamente a runtime(al momento
dell'esecuzione). La stessa cosa succede anche nei linguaggi di
programmazione.
Per quanto riguarda gli errori di logica, dubito che ci sia una sp oppure un
altro strumento che possa depistarli.
ernest
"Mauro Servienti" <maurose...@online.nospam> wrote in message
news:etAPPbZk...@TK2MSFTNGP09.phx.gbl...
Ernest Morariu
correttezza.
Secondo me, se vuoi fare una verifica sia dal punto di vista logico che
della sintassi è meglio che esegui i comandi e poi fai la rollback.
Altrimenti potrai avere delle sorprese. Comunque, per quanto riguarda gli
errori di logica, neanche l'esecuzione non ti da una garanzia assoluta, però
ottieni più garanzia.
ernest
"Pierluigi Terzoli" <pierluig...@hotmail.com> wrote in message
news:O#XQieZkE...@TK2MSFTNGP14.phx.gbl...
Mauro Servienti
Ernest Morariu wrote:
> Mauro,
>
> non riesco a capire il collegamento fra la transazione e la sintassi.
> Se un comando sql ha *errori di sintassi* non viene proprio eseguito.
> Sono i comandi che contengono errori di logica(non di sintassi) che
> possono essere parzialmente eseguiti, quindi che richiedono la
> presenza di una transazione se non si vuole fare una "mezza" modifica.
infatti il ns collega non vuole verificare gli errori di logica, ma
semplicemente quelli di sintassi e per fare ciò, lo dice lui non io, esegue
il comando in oggetto verso il db all'interno di una transazione e se il
comando va in errore, sulla base dell'errore restituito, capisce che la
sintassi non è valida altrimenti la sintassi è valida, al tremine esegue
sempre un rollback. Può non essere un metodo molto ortodosso ma se
funziona...
la risposta di Alex risolve il problema nel caso di SQL Server e nella
possibilità di un round-trip verso il db l'opzione SET PARSE ONLY esegue
esattamente quello che fa il QueryAnalyzer quando fai il parse del comando
prima dell'esecuzione.
In definitiva credo che voglia costruirsi un sorta di QueryAnalyzer per
poter gestire comandi SQL a fronte di vari dbms e di conseguenza ha bisogno
di un parser per verificare la validità sintattica del comando prima
dell'esecuzione. Con la risposta di Alex sa che il lavoro in questione può
farlo fare a SQL server senza reinventare l'acqua calda.
>
> Gli errori di logica credo siano verificabili solamente a runtime(al
> momento dell'esecuzione). La stessa cosa succede anche nei linguaggi
> di programmazione.
> Per quanto riguarda gli errori di logica, dubito che ci sia una sp
> oppure un altro strumento che possa depistarli.
Questo direi che è al di la di ogni dubbio, se nella mia testa voglio fare
una somma e invece scrivo una divisione difficilmente il compilatore mi
segnalerà un errore.
> ernest
>
Saluti,
Pierluigi Terzoli
QueryAnalyzer (come dice il buon Mauro) e segui:
- Prova a scrivere: select ciccio from pappa. Vicino al tasto che ti
permette di eseguire il comando (a sinistra) ce ne uno che effettua un
banale controllo formale. Infatti il comando risulta formalmente corretto
(nel senso che è conforme alle carte sintattiche del liguaggio SQL).
Ovviamente se tenti di eseguirlo ottieni un errore.
Ok ? E qui abbiamo chiarito il primo punto, cioè cosa significa un controllo
formale. Esattamente quello che fanno i compilatori, controllano la
correttezza della sintassi ma non scongiurano gli errori a runtime
- Se non esiste un metodo in ADO.NET che mi effettua un controllo formale,
cerco di costruirmelo mediante un artifizio. Ci ho pensato 3 minuti e poi mi
sono detto:
(la prima ipotesi che mi è venuta in mente) eseguo il comando, controllo se
va a buon fine, e poi non registro eventuali modifiche sul DB che il comando
stesso fa scaturire.
Mi spiego meglio, vorrei verificare la validità del seguente comando sql:
INSERT INTO Messaggi (Id,Testo) VALUES (20,'ciao')
Attenzione, RIPETO, voglio solo verificare la sua validità e non inserire in
questo momento la riga in questione sul DB.
Quindi, l'espediente quale potrebbe essere ??
metto il comando in una transazione che poi non termino mai ..... capito, è
un espediente !!
Ne convieni, Ernest ??
Pierluigi.
"Ernest Morariu" <REMOVEM...@gesora.com> ha scritto nel messaggio
news:u3p2XmZk...@TK2MSFTNGP14.phx.gbl...
Ernest Morariu
> INSERT INTO Messaggi (Id,Testo) VALUES (20,'ciao')
> Attenzione, RIPETO, voglio solo verificare la sua validità e non inserire
in
> questo momento la riga in questione sul DB.
Si, ma "verificare la validità" da che quale punto di vista ? Solo della
sintassi o anche della logica ?
Se ti basta verificare solo la sintassi, allora basta quel "set parse on",
niente transazioni, rollback o robe del genere.
Se invece vuoi fare anche una verifica da punto punto di vista logico,
allora non ti basta "set parse on" perché, ad esempio, se nella tua tabella
Messaggi il campo Testo e un varchar2(3), allora il comando di sopra (che
tenta di inserire la constante 'ciao' di 4 caratteri) è corretta dal punto
di vista sintattico, ma a runtime otterrai un bel errore. In tale
situazione, per depistare questo errore devi eseguire il comando all'interno
della transazione e finire con rollback per non fare le modifiche
persistente.
Decidi tu quale soluzione adattare in base a quello che vuoi fare; tutto
dipende fino a che punto/a che livello vuoi "spingere" questa verifica.
> metto il comando in una transazione che poi non termino mai ..... capito,
è
> un espediente !!
Si, però è quello che ti ho proposto anche io.
Il fatto che utilizzi la transazione vuol dire ti interessa la correttezza
del comando sql anche dal punto di vista logico non solo della sintassi.
Se vuoi fare solo una verifica della sintassi(formale), allora non ti serve
la transazione, fai come dice Alex e hai risolto il problema.
Come ti dicevo sopra, decidi tu, in base a quello che vuoi fare, quale è la
soluzione.
ernest
"Pierluigi Terzoli" <pierluig...@hotmail.com> wrote in message
news:#NOLYwZk...@TK2MSFTNGP11.phx.gbl...
Pierluigi Terzoli
Mi piacerebbe una soluzione DB engine indipendent ;)))
"Ernest Morariu" <REMOVEM...@gesora.com> ha scritto nel messaggio
news:%23xjktPa...@TK2MSFTNGP12.phx.gbl...
Ernest Morariu
:-)) Ho intuito questo dall'inizio. E' per quello che la mia prima risposta
è stata: "No, non credo sia possibile".
Tutte le soluzioni presentati qui sono db engine *dependent* . :-))
ernest
"Pierluigi Terzoli" <pierluig...@hotmail.com> wrote in message
news:eyTVXYak...@TK2MSFTNGP14.phx.gbl...