I would like to use existing Delphi code to write SQL Server stored procedures.
In the past I used extended stored procedures, somehow a dll compiled by Delphi wrapped by a SQL Server extended stored procedure.
Extended stored procedures are now deprecated, so somehow I wonder if there is a solution, even in the "trick domain", like some sample CLR code that wraps a normal dll or something like that.
Just to give you an example:
I insert in the db some documents by encrypting them and I would like to create a kind of API based on SQL Server functions / procedures for inserting or reading documents, so other people accessing sql server can call those functions.
Of course an alternative solution is to use webservices but I would like to try the SQL Server way first.
Note: I don't want to use Delphi Prism, my code is for XE2.
Unsafe SQLCLR assemblies can p-invoke native dlls. A better way would be to expose the native DLL services as a COM interface and use COM interop from SQLCLR, or even call the COM APIs directly from SQL via OLE Automation Procedures. An even better way would be to rewrite the Delphi code as CLR code and invoke it directly as SQLCLR procedure. And the best way would be to use SQL Server native encryption features.
Not to mention the fact that CLR in SQL Server is a guaranteed deep performance hit. Keep to the standard CRUD operators and you should be fine. The other way to do it is to use the file system as your encryption mechanism. If you are only trying to prevent casual access to docs this is a fine way to go. Otherwise it might be time to rethink your access protocol.
CLR in SQL Server is a convenient bad idea. Use it sparingly if at all.
Related
We're using MSMQ to insert records from a service into SQL Server tables in multiple locations. I'd like to insert into this MSMQ queue from SQL Server - that way, rather than come up with my own way to add messages to each server, I can just piggyback on the existing infrastructure and code.
It looks like the best way to do this is by using a CLR.
However, all the code I've found to create MSMQ messages from a CLR require UNSAFE mode. Is there a way to do it in EXTERNAL_ACCESS mode instead?
This is most likely because System.Messaging is not a supported library for CLR. Since it's not a supported library, it does not meet the requirements of SAFE or EXTERNAL_ACCESS.
Read more here: http://msdn.microsoft.com/en-us/library/ms403279.aspx
I know we can use functions in SQL Server, but my question here:
If I write a udf, do I have to use something 'visual basic', or something, could you please provide a simple example, how to load that function, because if it is a simple function is enough to execute it, but if it uses vb?
SQL Server UDF (User Defined Functions) are usually written in TSQL, but they can also be written using the CLR.
A typical use of a CLR Function or Stored Procedure is for string manipulation (which TSQL wasn't really designed for and only has limited functionality built-in)
I am looking to insert and update records in a database using functions and logic that are not available in SQL Server or any other RDBMS for that matter. After Googling around a bit this morning, I have come across the concept of Extended Stored Procedures. As far as I can tell, I should be able to compile my desired functionality into a dll, make a stored proc utilizing that dll to do the inserting/updating.
However, most of the articles and examples I have come across are somewhat dated (~2000). Are extended stored procedures still an acceptable practice? I am far from an expert in this area, so any other suggestions or comments would be greatly appreciated.
If you're using SQL Server 2005 or later, SQL CLR is the area to look at. You can call .NET code from within SQL Server.
This article on MSDN is a good place to start.
Are extended stored procedures still
an acceptable practice?
No, they are officialy deprecated and will be dicontinued in a future release. See Deprecated Database Engine Features in SQL Server 2008 , in the Features Not Supported in a Future Version of SQL Server table:
Extended stored procedure programming: Use CLR Integration instead.
I usually recommend against using CLR procedures, in most cases you can refactor the problem you are facing, into something that Transact Sql can handle.
Of most concern is the procedural approach that often accompanies the use of CLR procedures, when a relation database performs best when performing set based operations.
So the first question I always ask, is there anyway to refactor the problem into a set based operation.
If not, then I ask why would you want to execute the code inside of the database server, instead of in an application layer? Think about the performance impact you might have by placing the logic inside the database. (This might not be an issue if your db server has plenty of extra processing time).
If you do go head with CLR procedures, I think they are best applied to intensive calculations and complex logic.
I just learned I can't use SMO in ASP.NET without either SQL or a full SMO install on the application server. I'm not allowed to do that, so I can't use SMO.
What other libraries do the same thing as SMO but don't require an MSI installer or COM registrations?
I know I could send DDL to the server inside ADO.NET commands, but that is exactly what I was trying to avoid by using SMO.
What was nice about SMO:
Object oriented API for querying meta-data (columns, data types) that didn't rely on inconsistent COBOL-like DDL.
Didn't require querying undocumented stored procedures, system stored procedures or tables which break every few versions.
Off the top of my head I can think of ADOX and DMO, but both were COM based APIs.
SMO is running T-SQL under the covers. You could prototype in SMO and then watch in profiler to get the T-SQL.
It is probably an EULA violation, but you could redistrib the SMO assemblies side-by-side with your app, nothing to install in that case. I don't think their installer hits the registry. Pretty easy to bust open the SQLServerManagementObjects.msi and find out.
I have a SQL Server stored procedure which has been in use for years. This stored procedure calls lots of other procedures. I would like to extract each inside procedure one at a time and implement its business logic to a .NET Class project.
In order to do that, I have to call .NET assembly from parent stored procedure and the returned result will be used by parent procedure. Since SQL Server 2005 and higher has CLR integration, so I think, executing .NET assembly inside stored procedure [or any Database objects] should not be a big deal, can you please point me some references where i can find examples or article to implement it?
Thank you very much for your help .
I really feel that this would be an inappropriate use of SQL CLR. The purpose of CLR integration is to support complex data types and operations that are normally very hard to do in pure SQL (such as sequences, regular expressions, hierarchy, geospatial, etc.) Not to implement a domain model in your database.
Domain models and business logic are separate from relational/data models. They should be in a proper business tier of some sort. Don't hack them into a database using the CLR.
(Note: I use SQLCLR a fair bit. I am not railing on CLR integration. I just don't think that this question reflects a wise design decision.)
MSDN
Building my First SQL Server 2005 CLR
An Intro to CLR Integration in SQL Server 2005
For loads more ;)
I think you should use SQL Server Integration Services (SSIS). As far as I understand, it solves this case, to orchestrate the procedure calls and gives you much more too..
I'm not too sure if moving this decision outside the db layer is a good decision.
Hope it helps..