taccio ha scritto:
Se è per questo su sql server 2005 hanno disabilitato anche il clr che anchesso può fare innumerevoli danni, però si sono sforzati un tantinello per supportarne l'integrazione... della serie microsoft agli utenti lo disabilita così che se lo vuoi realmente usare lo riabiliti.
l'utilizzo del CLR ha diversi vantaggi e va utilizzato, come tutto del resto con criterio, vi sono contensti dove è indispensabile ma da qui ad usarlo o peggio abusarne ce ne passa.
Difatti l'utilizzo va visto nel contesto TSQL e non come sostituto pertanto l'inserimento di dati va fatto sempre tramite un INSERT e non tramite CLR
Il terrore che molti dba e sistemisti hanno e che molti sviluppatori utilizzino queste tecnologie per colmare le loro lacune.
Facciamo un esempio pratico:
quanti ancora oggi nel 2007 usano il metodo AddNew per aggiungere dati a un recordset quando basterebbe richiamare una stored procedure parametrica d'inserimento??
inoltre di default sono state disattivate innumerevoli altre funzioni.
Hai letto bene il motivo della scelta??
Per diminuire la superficie di attacco, si torna sempre al discorso se installo MSSQL sul mio computer di casa, lavoro e sviluppo come utente administrator con security ntfs everyone full control allora non ha senso avere queste restrizioni.
Ma esistono situazioni un po' più complesse dove è bene che i dati custoditi nel database non siano accessibili a tutti ed inoltre c'è un piccolissimo particolare, ovvero nella stragrande maggioranza dei casi il server MSSQL è diverso da quello web e quindi xp_cmdshell non servirebbe a nulla.
in merito alla faccenda della modifica del service pack 3 beh io tuttora non credo sia necessario impedire il lancio di dtsrun per import / export o altre menate, e dunque pur non dando privilegi di sysadmin tramite exchamotage avevo riattivato il mio bravo xp_cmdshell. Poi cambiati gli scenari da 4 mesi circa non avendo più necessità ho fatto retromarcia.
scusa ma non vedo comunque la necessita di usare xp_cmdshell per lanciare un dts, ti basta usare sp_start_job e quindi usare MSSQL Agent e relativi job
con estremo rispetto per le vostre opinioni, che sicuramente saranno più corrette delle mie (dati i riconoscimenti MVP che avete), a prescindere dalla soluzione della intranet che deve implementare il nostro amico, non credo sia assolutamente deprecabile l'uso di strumenti potenzialmente molto dannosi se ben controllati e protetti e sicuramente in sqlserver 2005 non avrei usato xp_cmdshell ma il clr disattivato da mamma microsoft ma caldamente consigliato dalla stessa anche a sostituzione di normale Transact-Sql
http://msdn2.microsoft.com/en-us/library/ms345147.aspx
la mia è solo un opinione che spero non abbia reso in maniera arrogante dato che rispetto sinceramente le opinioni degli altri anche se differiscono dalle mie.
Aspe aspe nell'articolo da te citato non è caldamente consigliata la sostituzione di TSQL con l'uso del CLR ed questo è esattamente il messaggio che sistemisti e dba NON vogliono a giusta ragione che passi
Ti riporto un passaggio del documento da te citato "Transact-SQL is best for situations in which the code will primarily perform data access with little or no procedural logic. "
Pertanto per tutte le operazioni di gestione dati INSERT, UPDATE e DELETE si deve continuare ad usare TSQL mentre va utilizzata l'integrazione del CLR ad esempio per creare Custom UDF ma qui poi arriviamo a toccare anche problematiche di architettura dove sarà necessario valutare dove implementare la funzione se lato rdbms o lato applicativo
Concludendo in quanto stiamo andando parecchio fuori dal topic iniziale innovazione del CLR è un ottima cosa ma va vista ed usata come aggiunta a TSQL e non in sostituzione dello stesso
