I'm watching a webcast on CLR functions/procs and have a question:
If I create an assembly for my database using some .dll, is that .dll now locked by SQL Server?
I'm concerned of a situation where developer says the assembly code is bad. Developer presents new version of .dll .
- Will I get "Access denied, file is in use" when I try to replace the .dll ? Even if the assembly is used in a derived table column?
Thanks.
The file is not present on the file system. The assemblies is loaded into the database so it has to be placed here. The only thing that could possible cause problems is that you can′t drop an assembly which is used by depended procedures / functions etc.
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
In addition, if you would like to deploy a newer version of a dll you previously registered with the server (using create assembly statement), you can have a look at alter assembly statement.
-Mat
|||Good, I like that the file is no longer needed once uploaded into the database.
The ALTER ASSEMBLY statement looks promising, but is there anything that could hold an assembly-level lock because it's in use, preventing one from updating it?
Is there any sort of testing on dependents before being able to alter an assembly? For instance, I change an assembly method signature from one to two inputs, but database function expects to use one and only one. Another example, I remove a class that corresponded to a database type.
|||Extensive work has been made in ALTER ASSEMBLY to make sure that it doesn't break any dependencies, including Function/Procedure/Triggers entry-point, UDTs, computed column definitions, persisted CLR expressions, or any schema-bound database code in general, so you should not have any issues there.
The ALTER ASSEMBLY statement will take an exclusive lock on your assembly, and so it will have to wait until the current users of this assembly are done. This is not very different than when you modify other database objects.
Hope this helps!
No comments:
Post a Comment