I'm using since SQL Server 2012 that support CLR Assembly trigger (coded with C#).
But I'm now finding possibility to move Azure SQL but it says CLR Assembly is not supported.
Is it sure that Azure SQL doesn't support CLR Assembly and no way to do it?
Msg 10341, Level 16, State 100, Line 5
Assembly 'MyProject.SQLCLR' cannot be loaded because Azure SQL Database does not support user-defined assemblies. Contact Azure Technical Support if you have questions.
I also found this article but unclear for me.
Does or does not SQL Azure support CLR assemblies?
The fine manual indicates that an sql like:
CREATE ASSEMBLY SomeName
FROM 0x...
WITH PERMISSION_SET = SAFE;
will work; all you have to do is turn your dll into a string of hexadecimal number pairs representing the bytes and put them in where the ... are. The example is at the very bottom of the MSDN doc. It would be important to note though that that doc explicitly states its advice is applicable to Azure SQL Managed Instance which is a relatively recent provision; ensure that is what you have deployed. See this blog for a more in depth discussion
Related
Im using SQL Server 2016. My DB contains Web service calls and .net Assemblies incorporated (CLR Functions).
I'm planning to move my DB to Azure SQL. Is it possible to call Webservices/CLR functions from Azure SQL? I see this article says its not possible. Is there any update/other way around?
How does Cosmos DB support support w.r.to this scenario? Please Suggest
SQL Azure does not support CLR in-database. However, SQL Azure Managed Instance does. So, please look into that option.
Your other possible approach is to consider what logic exists in CLR and see if you can move to T-SQL equivalents. Since CLR was added, we now have batch mode processing (Columnstore) as well as in-memory tables/natively compiled stored procedures. Both options are pretty fast alternatives that may solve your problem. In-memory tables are supported on SQL Azure with >= 1 core due to associated memory requirements. Columnstore works on S3 and above in Standard and on Premium/V-core options.
You cannot use CLR functions on Azure SQL Database but you can use CLR functions on an Azure Managed Instance with some restrictions. Managed Instance cannot access file shares and Windows folders, so the following constraints apply:
Only CREATE ASSEMBLY FROM BINARY is supported.
CREATE ASSEMBLY FROM FILE is not supported.
ALTER ASSEMBLY cannot reference files.
To learn about Azure Managed Instances, please visit this documentation.
Can somebody please explain the various scenarios that would make one choose SQLCLR vs Python vs R.
I understand that R is a language and a library specifically designed for statistical analysis and data mining so I understand leveraging that capability when appropriate, but can R (on SQL Server) do more and call additional external libraries like CLR assemblies can?
Is Python meant as an eventual replacement for C# SQLCLR? It seems to me, from what I've read, that Python can simply be embedded inside a stored procedure and then interpreted upon execution as opposed the compiled nature of CLR assemblies, but otherwise the capabilities are the same? Are they?
I'll try to answer your questions:
SQLCLR was introduced in SQL Server 2005, as a way to embed CLR (.NET) in the SQL Server engine. E.g with SQLCLR your .NET code is running in the same memory and process space as SQL Server itself. The way it works (simplified) is that you create an assembly and registers it with SQL Server (CREATE ASSEMBLY). You then create "wrapper" T-SQL stored procedures/functions/triggers etc., against your .NET methods, and it is these procs that you execute at runtime.
R was introduced in SQL Server 2016, and Python in SQL Server 2017 in order to give SQL Server machine learning capabilities. As opposed to .NET, neither R nor Python run embedded in SQL Server, but when you call R/Python code inside SQL Server, calls are made out to the R/Python engine sitting outside SQL Server's memory/process space. This is an important distinction between SQLCLR and R/Python:
SQLCLR code executes in-memory/in-process with SQL Server
R/Python executes outside of SQL Server.
As a side note; I have a series of blog-posts discussing the internals of SQL Server R Services (even if the posts talk about R, everything in there are applicable to Python as well).
As for capabilities; R/Python in SQL Server can do no more, no less than what "standalone" R/Python can do: as mentioned above the actual execution of R/Python happens outside of SQL Server as well.
Personally I do not think Python is a replacement for .NET in SQL Server, I see it as an additional tool in your toolbox. Where I work we use both SQLCLR as well as R/Python (in SQL Server). We have 100's of SQLCLR assemblies in our production databases, doing weird and wonderful things (sending messages to RabbitMQ etc., etc.), and IMHO it'd be very hard to replace that with Python, especially seeing that you'd immediately get a perf degradation - compiled code (SQLCLR) vs. interpreted code (R/Python).
Hope this helps.
Niels
I have a CLR function that I want to deploy with permission_set = unsafe
The assembly is signed with a public/private key file and I've created an assymtric key, created a login using that asymmetric key and given that login the permission for unsafe assemblies
If I want to deploy the assembly can I just execute the .publish.sql found under ./bin/debug be used to deploy the CLR assembly .dll?
Thanks in advance
If you have already set up the perquisite stuff, then I am curious as to why you didn't just attempt to execute that file to see for yourself as that would have answered this question, right? ;-) But yes, those three steps are all you need to do in order to be create (and use) an Assembly marked with PERMISSION_SET = UNSAFE.
Keep in mind that the "publish" script is always incremental. So you shouldn't take it as being a deployment script that will work in all situations. If you have done a build and made no changes, then it won't re-deploy the Assembly, unless there is an option to always drop-recreate the objects (I know there is for the database but don't remember for the Assembly). The "create" script, if you checked the option to generate it, always drops everything and recreates.
And just in case this was implied, the publish scripts generated by SSDT do not, by default, mess with server-level objects that are not part of the project ("part of the project" means that you have imported the master DB into the solution). So the full Create script won't (or at least shouldn't) remove the Login or Asymmetric Key from [master]. But, if needed, there are options for "Do not drop Logins" and/or "Do not drop Asymmetric Keys".
AND, just to mention since this question regards an older version of SQL Server: SQL Server 2017, which was just released, changes the rules a little for deploying Assemblies. The method described in the question will still work as it creates the Asymmetric Key first, but that is now required even for SAFE Assemblies. I describe (in detail) two options for dealing with this that both a) work in all versions back to SQL Server 2012, and b) work with the framework of Visual Studio and SSDT in a fully automated manner:
SQLCLR vs. SQL Server 2017, Part 2: “CLR strict security” – Solution 1
SQLCLR vs. SQL Server 2017, Part 3: “CLR strict security” – Solution 2
That first link (for Solution 1), is an adaptation of the method detailed in the following article that I wrote for SQL Server Central and that does work with SQL Server 2005 - SQL Server 2016:
Stairway to SQLCLR Level 7: Development and Security
This is more of a "just wondering" question. Is there any way to access the Windows Indexing service database through ODBC in MS Access or SQL Server? I know there are a million recursive programming ways to traverse the file system but if I was only looking for files with a certain name I would think something as simple as "Select Fullpath from CDrive Where FileName like '%HEVC%'" would be easier and more lightweight than other methods.
I can't seem to Google this since all it does is return a million results for ODBC DSN creation.
Foreword: My focus is on other projects, but this is an interesting topic.
Microsoft uses an EDB file to provide a central Indexing Service - MSDN. Based on the Microsoft SQL Server CE engine, it is lightweight offers a number of methods for access including addition of third party file type definitions.
However, there are differences...significant ones that prevent direct translations of EDB and CEDB. Comparing EDB with SQL Server CE
As I said, there are access methods. The ODBC you were hoping for was discontinued after Windows XP.
However, Microsoft has developed two methods:
Windows Search (client side)
Microsoft Search Server Express (server side)
Both methods allow for quick file searches and likely could be integrated into whatever warehouse architecture you have through APIs, for example. However, there are limitations on methods that the links point out.
I admit I cannot give a full answer since I was learning, too, but hopefully this can point you in the right direction.
Cheers,
Actually, Found something else here:
Querying the Index with Windows Search SQL Syntax
Works like a charm, just have to get used to the special SQL syntax. Works on Windows 10, just having a problem querying a Storage Space. I'll update if I find an answer.
I have a SQL Server database (2008) within which I have some CLR DLLs that SQL uses for various things.
Are these DLLs mirrored when I use SQL Mirroring? Our DBA says not, but I find this crazy and cannot find much info on it online.
Is it possible to mirror the CLR DLLs?
CLR Assemblies are stored in the database, and are mirrored as a part of the database. Each database has its own sys.assemblies view, and if you query the master.sys.assemblies DMV, you won't find the assemblies for other databases in the DMV. There are problems that you may encounter with having a database with assemblies in it mirrored. The first being, if you have an External Access or UNSAFE assembly and you used the TRUSTWORTY bit to allow the assembly in your database, this is disabled during the recovery process when you failover, so you have to re-enable it. If you signed the assembly with a certificate you have to create the certificate and login associated with the assembly on the mirrored server manually since this is stored in master, not in the database. The Assembly will be there, and so will your SQL Database Objects, but it may not function. You may also need to change the database owner name as a part of the failover.
http://sqlblog.com/blogs/jonathan_kehayias/archive/2008/03/06/clr-safety-issues-after-database-restore-to-new-server.aspx
If you want to validate what I say above, backup the user database with an assembly on it, and restore it to another server. Your assembly will be a part of the database.
Just to add the obvious point to what Jonathan said: your assemblies have to be deployed in the mirrored application database, not in msdb or some other database.