"Manuel Meinardi" <info@qdistudio.com> ha scritto nel messaggio news:1177945941.688556.240340@h2g2000hsg.googlegroups.com... > Esatto so che è semplice ma sono alle prime armi, mi servirebbe un > picclo spunto, poi credo di potermi arrangiare anche da solo. > Prima regola: creare stored procedure troppo generiche è un male, perché sei costretto a ricorrere al T-SQL dinamico e questo è molto male :-) Facendo pratica capirai, e più in la' la scelta di ricorrere al T-SQL dinamico in certi particolari casi sarà più consapevole e chiara, ma fidati che la risposta non sarà mai: "il T-SQL dinamico serve per creare stored procedure generiche". Tornando alla tua esigenza oltre a leggere con attenzione un po' dei post che ti ha suggerito Marcello, io ti proporrei una soluzione che comunque dovrebbe andarti bene e che non prevede l'uso di stored procedure e nemmeno di T-SQL dinamico. Praticamente sfrutto una user function con parametri in sostituzione della stored procedure. Questo ti permette di creare lato client una select sulla user function specificando di volta in volta i campi di cui hai realmente bisogno oltre che ad un probabile elenco di campi per l'ordinamento del resulset. Il pseudo codice non testabile della user function che si basa sulle info generiche che hai passato è questo: create function ufnCocktailsRic ( @ID_Cocktail varchar (32), @Code varchar (64), @Valutazione int, @Categoria varchar (64), @Base varchar (64) ) returns table as return ( select c.ID_Cocktail, c.Code, c.Valutazione, c.ID_Categoria, c.ID_Base, t.Code as Categoria, b.Code as Base from t_Ap_Cocktails c inner join t_Ap_Categorie t on c.ID_Categoria= t.ID_Categoria inner join t_Ap_Base b on c.ID_Base= b.ID_Base where c.ID_Cocktail= isnull (@ID_Cocktail, c.ID_Cocktail) and c.Code like '%' + isnull (@Code, '') + '%' and c.Valutazione= isnull (@Valutzione, c.Valutazione) and t.Code= isnull (@Categoria, t.Code) and b.Code= isnull (@Base, b.Code) ) Con questa funzione in mano, lato client ti basterà eseguirci sopra le tu select con i campi che potranno variare di volta in volta, ritornando ai tuoi esempi: > se voglio tutti i Code dei cocktail dove il Code contiene 'ca' -- > >sp_Procedura 'ca', null, null, null, null,'t_Ap_Cocktails.Code' select distinct Code from ufnCocktailsRic (null, 'ca',null,null,null) order by Code > se voglio tutti i Code cocktail dove il Code contiene 'ca' e sono a > base di rum -->sp_Procedura 'ca', null, null, null, > 'rum','t_Ap_Cocktails.Code cocktail' select distinct Code as cocktail from ufnCocktailsRic (null, 'ca', null, null, 'rum') order by cocktail > se voglio sapere la base e la categoria con la quale è fatto il > cocktail con ID = '123kjbhu22h35jh25342hv5jh3425hju' --> > sp_Procedura null, null, null, '123kjbhu22h35jh25342hv5jh3425hju', > null,'t_Ap_Base.Code Base, t_Ap_Categorie.Code Categoria' > select distinct Base, Categoria from ufnCocktailsRic ('123kjbhu22h35jh25342hv5jh3425hju',null,null,null,null) order by Base, Categoria Occhio alla necessità di usare o meno la clausola distinct nella select per evitare righe duplicate. E tieni presente che, se non sbaglio, lato client puoi acceedere alla user function come fosse una sp con i suoi parametri. Praticamente non devi comporre una banale stringa con la select finale che ti serve (quella degli esempi), ma devi definire un command con 5 parameter e nel text dell'ogetto command ci piazzi ad esempio: "select distinct Code from ufnCocktailRic (@ID_Cocktail, @Code, @Valutazione, @Categoria, @Base order by Code" Valorizzi quindi i 5 parameter che sono referenziati nel text e poi generi dal command il tuo bel recordset che andrai ad usare secondo le tue necessità. Questo è necessario per non incorrere nei problemi derivanti da quello che si chiama SQL-injection. Mega riassunto finale: non usare il T-SQL dinamico, ne' lato server, ne' lato client. Quando ti sarai fatto le ossa caso mai potrai decidere diversamente, ma per adesso no! :-) Ciao, Alessandro