Come posso implementare questa feature con SQL Server 2005?

giovedì 18 giugno 2009 - 10.58

advapi Profilo | Newbie

Ciao a tutti,
scusate se vi distrubo, è da ieri che sto sbattendo dietro questo problema ma non riesco a venirne a capo... io ho una store procedure che accetta 5parametri di tipo varchar(128) come parametri di ingresso, questa store viene utilizzata da un webservice per mascherare l'accesso al DB diretto con l'utilizzo di un WebService .NET. La mia store procedure dovrebbe fare da interfaccia interrogando altre tabelle e chiamare a sua volta altre store procedure evitando l'accesso diretto a queste in base a criteri di autenticazione gestiti a livello di webservice.

Considerate la store procedure INTERFACCIA(@P1 varchar(128), @P2 varchar(128),@P3 varchar(128),@P4 varchar(128),@P5 varchar(128))

Per adesso possiamo considerare la tabella StoreProcedureName dove sono contenuti i nomi delle store procedure e la tabella StoreProcedureDetail dove è specificato il tipo di parametro e il nome)

visto che i 5 parametri sono fissi ma le store procedure richiamate possono avere un numero minore di parametri, devo ciclare con un indice sul numero di parametri presenti nella StoreProcedureDetail e prendere in considerazione il numero di parametri dati, questo lo faccio all'interno dell'esecuzione di un cursore che cicla sulla StoreProcedureDetail in questo modo :

OPEN ParamCursor
FETCH NEXT FROM ParamCursor into @SP_PARAM_NAME, @SP_PARAM_TYPE
WHILE @@FETCH_STATUS = 0
BEGIN
set @paramCount = @paramCount + 1
declare @tmp varchar(20)
set @tmp = '@P'+ CAST(@paramCount AS varchar(10))
print @tmp
set @SQL = @SQL + N' ' +N'@' + @SP_PARAM_NAME + N'='
FETCH NEXT FROM ParamCursor into @SP_PARAM_NAME, @SP_PARAM_TYPE
END

Quello che avrei bisogno di fare è di andare a leggere il valore contenuto in @P + indice ... esiste un modo? in C# avrei utilizzato la reflection, l'unico modo che mi viene attualmente in mente è quello di fare un case switch ma se il numero di parametri dovesse crescere sarei in difficoltà...

Grazie ciao

lbenaglia Profilo | Guru

>io ho una store procedure
>che accetta 5parametri di tipo varchar(128) come parametri di
>ingresso, questa store viene utilizzata da un webservice per
>mascherare l'accesso al DB diretto con l'utilizzo di un WebService
>.NET. La mia store procedure dovrebbe fare da interfaccia interrogando
>altre tabelle e chiamare a sua volta altre store procedure evitando
>l'accesso diretto a queste in base a criteri di autenticazione
>gestiti a livello di webservice.

Fino a qua in tuo discorso fila liscio come l'olio.

>Considerate la store procedure INTERFACCIA(@P1 varchar(128),
>@P2 varchar(128),@P3 varchar(128),@P4 varchar(128),@P5 varchar(128))
>
>Per adesso possiamo considerare la tabella StoreProcedureName
>dove sono contenuti i nomi delle store procedure e la tabella
>StoreProcedureDetail dove è specificato il tipo di parametro
>e il nome)
>
>visto che i 5 parametri sono fissi ma le store procedure richiamate
>possono avere un numero minore di parametri, devo ciclare con
>un indice sul numero di parametri presenti nella StoreProcedureDetail
>e prendere in considerazione il numero di parametri dati, questo
>lo faccio all'interno dell'esecuzione di un cursore che cicla
>sulla StoreProcedureDetail in questo modo :
>
>OPEN ParamCursor
>FETCH NEXT FROM ParamCursor into @SP_PARAM_NAME, @SP_PARAM_TYPE
>WHILE @@FETCH_STATUS = 0
>BEGIN
> set @paramCount = @paramCount + 1
> declare @tmp varchar(20)
> set @tmp = '@P'+ CAST(@paramCount AS varchar(10))
> print @tmp
> set @SQL = @SQL + N' ' +N'@' + @SP_PARAM_NAME + N'='
> FETCH NEXT FROM ParamCursor into @SP_PARAM_NAME, @SP_PARAM_TYPE
>END
>
>Quello che avrei bisogno di fare è di andare a leggere il valore
>contenuto in @P + indice ... esiste un modo?

Qua invece non ho capito niente
Ricorrere al Dynamic SQL per richiamare una sp equivale a perdere gran parte dei vantaggi offerti dalle sp stesse.
Per quale motivo ti stai complicando così la vita?

>Grazie ciao
Prego.

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

advapi Profilo | Newbie

Ciao Lorenzo,
si mi sono dimenticato di specificare il perchè di questo giro mistico/perverso... attualmente gli utenti accedono al DB tramite ActiveX o chiamate a DB dirette, con questa "interfaccia" tentiamo di avere un unico punto di accesso, dove non forniamo più il nome diretto della SP ma un alias e il passaggio dei parametri avviene senza tipizzazione (si lo so è un macello e si perdono i benefici di avere i tipi definiti, ma dopo averne parlato con il mio CEO siamo giunti a conclusione che sia la situazionem igliore per il nostro problema)

Grazie ciao

Paolo

lbenaglia Profilo | Guru

>con questa "interfaccia" tentiamo
>di avere un unico punto di accesso, dove non forniamo più il
>nome diretto della SP ma un alias e il passaggio dei parametri
>avviene senza tipizzazione (si lo so è un macello e si perdono
>i benefici di avere i tipi definiti, ma dopo averne parlato con
>il mio CEO siamo giunti a conclusione che sia la situazionem
>igliore per il nostro problema)

Io tornerei indietro, fornendo un metodo ad-hoc per ogni sp con i parametri tipizzati necessari.

>Grazie ciao
Prego.

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

goldfix Profilo | Newbie

ciao...

premetto che non è proprio il massimo quello che stai cercando di fare.

Cmq se ho capito bene, te ne dovresti uscire con queste due viste di sistema:

use TuoDB;
select * from INFORMATION_SCHEMA.ROUTINES;
select * from INFORMATION_SCHEMA.PARAMETERS where SPECIFIC_NAME = 'dbo.TuaStored';

olaaaa
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 !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5