I know this is not an easy one, nor that it should be very popular. But does anyone know the best way of calling an external assembly with parameters in a trigger or a Stored procedures ? I have tried the CLR strored proc, but I can't add the reference that I need to update a DB2 database. Therefore, I would like to call an external assembly that could do it. Then I would call this assembly in a update trigger.
In SQL Server 2008 R2, the proc sys.xp_cmdshell is blocked by default. So the security guys here will not want to turn that on.
Thanks !
This is obvious that you can't treat a CLR project as a normal project and add references to it. Read this article for more information:
http://sqlserver-training.com/adding-external-references-to-sql-clr-projects/-
Related
Is there any way to implement change data capture on SQL to Azure EventHub without using exe?
The code needs to run in the context of SQL Server only
SQL Server Version : 2014
Tried SQL CLR with Azure EventHub but not able to create all required assemblies on SQL database.
I'm trying to create the list of references by clicking adding new assemblies on SQL databases. These are the assembly references required as per my Visual Studio project
But adding one it requires another one and it seems end less. I'm not able to find all the assemblies on my system and i got few assemblies from internet. Many assemblies are added as UNSAFE. While I'm adding, getting always unsafe warning. After lot of struggles added only these assemblies
After much work i've configured my machine (win 7 x64, VS2010, SQL 2008 R2) to be able to debug stored procedures locally from within visual studio. My question is about how the debugging context is supposed to switch as you debug.
an example:
when debugging and I call another vb class the debugger follows and jumps to that class for me to step through. when I hit a sql call is there a way to tell the debugger to follow it there too?
currently the only way I can debug a stored procedure is to right click it and choose "step into" and provide values. Those values I have to determine by running my app, making edits, and writing down my param values I was going to pass into the stored procedure. Then going back and stepping into the stored procedure with those values allows me to track and use intellesense to debug the sql stuff.
What i'm looking for though is to have the debugger do the switching for me. So I don't have to do as much work to step through stored procedures. When I run my application and open one of my stored procedures to view the breakpoint symbols are not loaded but it does say it has auto-attached to the sql process and everything.
Wasn't sure if this was how sql debugging was supposed to go or if I did something incorrectly. Figured someone here might know what was going on. Thanks for looking!
my target framework was dot net 4 client profile. When I swapped to full dot net 4 framework and rebuilt everything started working like I thought it should. My only guess is that some of the sql-clr debugging stuff is trimmed out of the client profile?
Try the following.
The standard workflow to debug a CLR SQL assembly is the following…
Right-Click the project and select ‘Deploy’
Debug | Attach to Process…
Select the Process ‘sqlservr.exe’ and make sure it is the one with a Type of ‘T-SQL, Managed, x86 or x64’
Press the Attach Button
Is it possible to call a MATLAB command within a stored Procedure?, something like
EXEC(MATLAB_COMMAND(Argument1,argument2))
Without any working experience concerning SQL Sever 2008, I would say no. Referring to the mysql documentation, a stored procedure is described as:
A stored routine is a set of SQL
statements that can be stored in the
server.
The idea is to store SQL queries on your SQL server.
You should proceed to other way round. Access your SQL Server from MATLAB, eventually calling stored procedures. All you need is a jdbc driver, leveraging MATLAB's Java scripting capabilities.
I have seen a few posts here about using the native MSSQL 2008 functionality to debug and step through TSQL.
In a Visual Studio 2010 .NET C# console app, I use simple ADO.NET to send some params to a stored proc. I can run it in the debugger and see what happens in the .NET code up until the point where the SqlCommand is executed. How can I get the debugger (or any debugger) to fire on the MSSQL side so I can follow data from the C# all the way to/though the DB?
Thanks.
If you want to capture what is sent cross the wire, use SQL Profiler.
Using SQL Server Profiler
If you are having problems stepping into a stored procedure from Visual Studio:
How to: Enable Transact-SQL Debugging
Walkthrough: Debug a Transact-SQL Stored Procedure
[Please note: your mileage may vary; I've known systems where this just wouldn't work. So much so, I never try to step into TSQL any more...]
I often heard people saying that stored procedures are pre-compiled. What does it mean?
Actually we write the queries into the stored proc and then compile it. If any syntactic error is there, it complains. So if that is the case then the compilation is happening at that point of time.
Then, what does "Pre" refer to?
They are actually pre-parsed and syntax/semantics checked on CREATE and ALTER
"Compilation" to a query plan happens on demand
For an overview of compilation and re-use, see "Batch Compilation, Recompilation, and Plan Caching Issues in SQL Server 2005 "
The terminology (in what you mean) goes back to SQL Server 6.5. The "new" way highlighted in the previous white paper link started with SQL Server 7.0
In Microsoft SQL Server, stored procedures are compiled into a query plan the first time they are run.
At subsequent runs, they are sometimes recompiled from source, but not always. That is why they are called "pre-compiled".
Unless you specify that they should always be recompiled, or when you run sp_recompile to enforce recompilation at the next run time.
The sql content of the stored proc won't be parsed if you run it. The sql parsing can be very time consuming operation.
Precompiled: In Microsoft SQL Server, stored procedures are compiled into a query plan the first time they are run. At subsequent runs, they are sometimes recompiled from source, but not always. That is why they are called "pre-compiled"