Cini mi se da je odgovor ovde:

http://blogs.msdn.com/sqlclr/archive/2006/06/22/643554.aspx

Nemam problema sa Security-em jer sam svoje assembly-e u SQL CLR-u napravio kao unsafe (jer koriste izmedju ostalog Win32 API). Konkretno za jedan assembly mi prijavljuje gresku u vezi Remoting-a:


Znaci CLR pokusava da nadje assembly od Remoting-a u istom folderu gde je moj, umesto da ga trazi u GAC-u. Nisam se puno bavio sa SQL-ovim CLR-om, da li uopste on moze da radi sa assembly-ima koji se ne nalaze u njemu ?

Jesi li registrovao sve asemblije u SQL-u?

Malo komplikovanije resenje:


http://social.msdn.microsoft.c...9-f077-4043-9f76-a0460c1f9332/

Ma mora da se registruje u SQL serveru :)

evo iz dokumentacije:



Znaci CREATE ASSEMBLY u ruke i sprzi sve reference koje su ti neophodne.

Nisam stigao da se zahvalim, ali evo sada, veliko hvala

Nije moglo drugacije - sto mmix rece zapljunuo sam dlanove i uradio registraciju svih koriscenih assembly-a .... Malo je glupo, ne razumem zasto SQL CLR ne koristi GAC ?!
Nije to toliko zamoran posao koliko komplikuje deployment. Nije problem uzeti windir iz envroment-a da bih napravio pravu putanju do Microsoftovih assembly-a i da pri instalaciji mojih assembly-a odmah registrujem i moje, ali mi se na nekim masinama desava da je transakcioni log prepun. Kao zaobilazno resenje sam koristio preventivno truncate loga pre pocetka registracije, ali mi to ne deluje kao dobro resenje. Prvo, sta ako na nekom serveru previse mali log fajl, drugo sta ako se to DB adminu ne svidi ?

nisam to nikad probao, ali mi je ortak jednom natuknuo da moze umesto putanje do DLL-a da se stavi putanja na xml fajl sa manifestom koji pokazuje na GAC asembli, i onda samo registrujes manifest fajlove koje znas gde su :) Al kazem, nikad nisam probao to.

Nisam bas skapirao povezanost loga i registrovanje asemblija?

Sounds interesting Cim uhvatim slobodnog vremena istrazicu ovo. Koliko su mi se u pocetku zgadile zabrane koriscenja managed COM objekata u SQL 2005, sada pocinje lagano da mi se dopada SQL CLR, ali jos uvek ne dovoljno



Nisam ni ja Ima nekoliko baza, sve su iste - kopije jedne baze koja je samo distribuirana na vise servera. Provero sam i sve imaju transakcioni log koji ima unrestricted growth, ali na nekim masinama dobijam pri registraciji System.Web assembly-a (i samo pri njemu) gresku da je transakcioni log pun i da nije mogao da nastavi registraciju, dok na drugima prodje bez problema. Koristio sam flaster tehniku (zakrpi da radi i begaj kuci), ali mi ovo nije jasno.

Ok, defintivno ne prihvata xml manifest, upravo sam probao ne prepoznaje format kao PE. Probacu sad i binarni manifest pa cu ti javiti.

Ok, konacno sam povezao loncice da nisi ovo pokrenuo ne bih ovo ni provalio.


Evo sta se desava.

1. Ne moze se registrovati samo preko manifesta, a razlog za to je:
2. SQL CLR uopste ne koristi CLR, ne samo da ne zna da ucita assembly iz GAC-a vec to ni ne pokusava jer:
3. kad registrujes assembly sa CREAT ASSEMBLY SQL ucita DLL i (pazi sad ovo) smesti njegov id u master.sys.assemblies a KOMPLETAN DLL binary (da, ceo fajl) smesti u varbinary polje [content] u tabeli master.sys.assembly_files

Kad mu zatreba instanca tipa iz asemblija SQL CLR instancira asembli i sam tip direktno iz svojih master tabela, verovatno sa Assembly.Load(byte[]), dakle ne ucitava sa diska i ne ucitava iz GAC-a. Sto se njega tice nakon sto registrujes mozes slobodno i da obrises dllove sa diska.


Ovo sad objasnjava i tvoj drugi problem, kad uradis CREATE ASSEMBLY sa velikim asemblijem, isti ide u master-ov transaction log kao deo INSERT INTO sys.assembly_files transakcije.