Gestione errore in Stored procedure

giovedì 07 giugno 2007 - 20.11

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

nullatore Profilo | Junior Member

191 messaggi | Data Invio: gio 7 giu 2007 - 20:11

Le parti in gioco per questo problema sono 2: una tabella chiamata "tabellaA" e una stored procedure chiamata "scriviA".
La mia sp è del tipo:

PROCEDURE scriviA
@valore1 int,
@valore2 int
AS

BEGIN TRAN

INSERT INTO tabellaA(id,col1,col2) VALUES(1,@valore1,@valore2)

IF @ERROR<>0
BEGIN
ROLLBACK TRAN
RETURN 1
END

INSERT INTO taFellaA(id,col1,col2) VALUES(2,@valore1,@valore2)

IF @ERROR<>0
BEGIN
ROLLBACK TRAN
RETURN 1
END

COMMIT TRAN

RETURN 0

2 domande:
-perche quando creo la SP viene fatto un controllo (semantico) sul nome delle colonne che sto passando mentre non viene fatto per il nome della tabella che sto passando (la seconda INSERT è sbagliata intenzionalmente MA la creazione avviene lo stesso!)
- la gestione degli errori che faccio con "IF @ERROR" dopo la seconda INSERT è inefficace visto che non viene calcolata...infatti quel tipo di errore manda tutto in tilt e fa stoppare l'esecuzione della procedure, senza effetturare il ROLLBACK.
L'unica soluzione che ho trovato è aggiungere SET XACT_ABORT ON. E' una/la buona soluzione?

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: ven 8 giu 2007 - 18:02

>Le parti in gioco per questo problema sono 2: una tabella chiamata
>"tabellaA" e una stored procedure chiamata "scriviA".
>La mia sp è del tipo:
>
>PROCEDURE scriviA
>@valore1 int,
>@valore2 int
>AS
>
>BEGIN TRAN
>
>INSERT INTO tabellaA(id,col1,col2) VALUES(1,@valore1,@valore2)
>
>IF @ERROR<>0
>BEGIN
> ROLLBACK TRAN
> RETURN 1
>END
>
>INSERT INTO taFellaA(id,col1,col2) VALUES(2,@valore1,@valore2)
>
>IF @ERROR<>0
>BEGIN
> ROLLBACK TRAN
> RETURN 1
>END
>
>COMMIT TRAN
>
>RETURN 0
>
>
>2 domande:
>-perche quando creo la SP viene fatto un controllo (semantico)
>sul nome delle colonne che sto passando mentre non viene fatto
>per il nome della tabella che sto passando (la seconda INSERT
>è sbagliata intenzionalmente MA la creazione avviene lo stesso!)
Dunque, non te lo so dire con certezza, ma potrebbe essere che il controllo sulle colonne lo fa sulla dipendenza della tabella che le possiede. Quindi le colonne, una volta definita una tabella esistente, devono essere quelle.
Per quanto riguarda il nome di tabella "errato", la sp a mio avviso ti dà la possibilità di usare un oggetto che potrebbe essere creato all'interno del chiamante ad esempio. Quindi da una sp che crea l'oggetto a runtime, potrebbe essere chiamata una sp che non sa ancora se l'oggetto esiste. E quindi te lo fa fare. In generale, se esiste controlla le colonne e le dipendenze, viceversa "lascia correre"

>- la gestione degli errori che faccio con "IF @ERROR" dopo la
>seconda INSERT è inefficace visto che non viene calcolata...infatti
>quel tipo di errore manda tutto in tilt e fa stoppare l'esecuzione
>della procedure, senza effetturare il ROLLBACK.
>L'unica soluzione che ho trovato è aggiungere SET XACT_ABORT
>ON. E' una/la buona soluzione?
A parte il fatto che è @@ERROR, l'errore a runtime te lo dà per forza, non esistendo l'oggetto (e quindi non avendolo creato da nessuna parte). Essendo un errore non gestibile, perdi la possibilità di fare rollback.
Impostando il flag XACT_ABORT a ON sei sicuro che a qualunque errore, tutta la sotored procedure viene mandata in ROLLBACK.
Direi chè è una soluzione valida, anche se, in alternativa, potresti controllare se l'oggetto esiste dalle tabelle del catalog di sistema, e se la tabella non esiste, rollback.
ciao.
Alx81 =)

http://blogs.dotnethell.it/suxstellino

lbenaglia Profilo | Guru

5.625 messaggi | Data Invio: lun 11 giu 2007 - 21:30

>Dunque, non te lo so dire con certezza, ma potrebbe essere che
>il controllo sulle colonne lo fa sulla dipendenza della tabella
>che le possiede. Quindi le colonne, una volta definita una tabella
>esistente, devono essere quelle.
>Per quanto riguarda il nome di tabella "errato", la sp a mio
>avviso ti dà la possibilità di usare un oggetto che potrebbe
>essere creato all'interno del chiamante ad esempio. Quindi da
>una sp che crea l'oggetto a runtime, potrebbe essere chiamata
>una sp che non sa ancora se l'oggetto esiste. E quindi te lo
>fa fare. In generale, se esiste controlla le colonne e le dipendenze,
>viceversa "lascia correre"

E' proprio così e prende il nome di Deferred Name Resolution:
http://technet.microsoft.com/en-us/library/ms190686.aspx

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/
http://italy.mvps.org

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 11 giu 2007 - 21:49

>E' proprio così e prende il nome di Deferred Name Resolution:
>http://technet.microsoft.com/en-us/library/ms190686.aspx
Grazie per il link, molto interessante!
>
>Ciao!
Ciao!

Alx81 =)

http://blogs.dotnethell.it/suxstellino

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !