A few years ago I came across a T-SQL technique to validate a stored procedure in SQL Server, but I cannot find it again
Can probably script the stored procedure calls out with SET NOEXEC ON, so it doesn't actually run anything... This would allow you to catch a lot of basic errors (invalid objects, missing fields, etc.)
Is that along the lines of what you were talking about?
If so, there's a CLR mentioned in SQL Mag that seems to do what you're looking for.
Related
Apologies for the strange question here.
Long story short is that we have a Visual FoxPro .prg that will execute a query using SQLEXEC(), and then uses AFIELDS() to get Field Name, Field Type, Field Width (length), and Decimal Places of the resultset columns to store into a SQL table (even if selected from a temp table or dynamic SQL).
What I'm looking for it to be able to run this .prg from a SQL Server CLR, or even using xp_cmdshell without having to manually open a Visual FoxPro Application.
I've already attempted to recreate this functionality in a CLR alone but kept running into issues with nested INSERT INTO statements when using it as a CLR Stored Procedure.
Additionally, I've attempted to create as a CLR SQL Function, but it would attempt to execute our custom hooks and throw "Procedure does not exist" errors, even when surrounded with IF Object_ID() IS NOT NULL.
Also, as some queries may be results of a temp table, I am unable to use OPENQUERY or OPENROWSET.
The end goal here is to move away from our Visual FoxPro client entirely, but the ability to get the column metadata of anything thrown at it is holding us back.
(Not an answer really, writing here as in a comment it would be a mess)
If I understood you right, the table in question is a VFP table and have some stored procedure functions (maybe for insert\update\delete triggers, or validation check).
If that is the case, I am afraid you are out of luck. Your best bet might be having a VFP COM object in between or a VFP SP using SetResultSet() - that might fail if there are unsupported VFP commands.
On the other hand you are saying it starts with an SqlExec(), then likely it is not a VFP table. Then likely you could create a CLR function. Would it be possible for you to share more details, along with the VFP and C# codes.
I have a stored procedure that is called from a c# application.
The transaction is started and commited/rolledback from this c# application.
The stored procedure can do some inserts/updates in various tables, which will all be commited or rolledback by the calling application.
The problem is that the stored procedure also insert records into a logtable, which must survive the rollback.
What is the best way of doing this ?
I think I remember from a company I worked for long ago they had solved this by creating a stored procedure for the logging, and this stored procedure had some exotic statements that made it work outside the transaction, something like that. As I said, long time ago I could remember this wrong.
Some times ago, I've develop a tools that logged stored procedure execution in a databases table. The tools was written as a C# assembly compiled into the Database Server and based on differents SQL procedures and functions linked to its C# entry points.
To allow a rollback without the lost of all events allready logged, the C# assembly SHOULD used a full defined connectionString to connect to its database server (SERVERNAME\INSTANCE server param instead of local).
This is perhaps the solution used by your previous company.
Meanwhile, there are some disadvantages:
thoses connections was qualified as "external" and the "truthfully" databases parameters should be set to true to allow code execution if not signed
this solution is not supported on clouded databases (AWS RDS or Azure)
A new connection is created by C# methods
For this last reason and a customer need, I've rewrite a toolbox based on 100% T-SQL source code.
I've just write a response which can be usefull see: https://stackoverflow.com/a/32988757/1183297
I have been writing a CLR stored procedure that moves data from one database to another. I went with the CLR stored procedure because I like the .NET framework's ability to connect to remote servers better than I like linked servers, or openrowset, but I now find that my class is mostly embedded SQL strings. I was considering just using the CLR stored procedures to retrieve the data onto the local SQL Server, and then using a regular SQL stored procedure for the actual inserts and updates.
I'm not worried about pre-compilation of the procedure or performance, and I do like that the CLR procedure allows me to see all of the logic in one place, read from top to bottom.
Are there any reasons I should consider moving to a TSQL solution instead of CLR?
Thanks.
There are multiple reasons why you would stick to a regular stored procedure. I'll try to give you an overview of the ones that I know of:
Performance.
Memory issues. SQL Server only operates with its own max memory settings. CLR's go out of this bound. This could comprimise other applications (and the OS) running on this server.
Updatebility. You can update a Stored procedure with a simple script. CLR's are more complicated to update
Security. CLR's often require more security settings than regular t-sql.
As a general rule you only want to use CLR for:
interaction with the OS, such as reading from a file or dropping a message in MSMQ
performing complex calculations, especially when you already have the code written in a .NET language to do the calculation.
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
Tracing a stored procedure’s parameters handling
Is there any out-of-the-box functionality within SQL Server 2008 that will allow me to see a log of procedures executed, and the parameters passed?
We have a stored procedure whose return is used to determine if a user can log in to our application or not, and the stored procedure is returning some unexpected results. I'm trying to troubleshoot by seeing if the user ID is getting garbled as it's passed to the stored procedure, but I can't quite seem to find where I could go to check that.
Does such a log/viewer exist?
You can use SQL Trace, or SQL profiler, which is essentially a GUI for the same tool.
Details of SQL Trace here msdn.microsoft.com/en-us/library/ms191006(v=sql.105).aspx
Profiler here msdn.microsoft.com/en-us/library/ms181091.aspx
Pete has the right answer if you need to track everything that is run, but if you can modify the procedures yourself you can add logging functionality (something like inserting to a table with the relevant details) directly to the procedure. This avoids the potentially large performance impact of the profiler.
If you have a lot of Stored Procedures and you change the name of a column of a table, is there a way to check which Stored Procedures won't work any longer?
Update: I've read some of the answers and it's clear to me that there's is no easy way to do this. Would it be easier to move away from Stored Procedures?
I'm a big fan of SysComments for this:
SELECT DISTINCT Object_Name(ID)
FROM SysComments
WHERE text LIKE '%Table%'
AND text LIKE '%Column%'
There's a book-style answer to this, and a real-world answer.
First, for the book answer, you can use sp_depends to see what other stored procs reference the table (not the individual column) and then examine those to see if they reference the table:
http://msdn.microsoft.com/en-us/library/ms189487.aspx
The real-world answer, though, is that it doesn't work in a lot of cases:
Dynamic SQL strings: if you're building strings dynamically, either in a stored proc or in your application code, and then executing that string, SQL Server has no way of knowing what your code is doing. You may have the column name hard-coded in your code, and that'll break.
Embedded T-SQL code: if you've got code in your application (not in SQL Server) then nothing in the SQL Server side will detect it.
Another option is to use SQL Server Profiler to capture a trace of all activity on the server, then search through the captured queries for the field name you want. It's not a good idea on a production server, because the profile incurs some overhead, but it does work - most of the time. Where it will break is if your application does a "SELECT *", and then in your application, you're expecting a specific field name to come back as part of that result set.
You're probably beginning to get the picture that there's no simple, straightforward way to do this.
While this will take the most work, the best way to ensure that everything works is to write integration tests.
Integration tests are just like unit tests, except in this case they would integrate with the database. It would take some effort, but you could easily write tests that exercise each stored procedure to ensure it executes w/o error.
In the simplest case it would just execute the sp and make sure there is no error and not be concerned about the actual results. If your tests just executed sp's w/o checking results you could write a lot of this genericly.
To do this you would need a database to execute against. While you could setup the database and deploy your stored procs manually, the best way would be to use continuous integration to automatically get the latest code (database DDL, stored procs, tests) from your source control system, build your database, and execute your tests. This would happen every time you committed changes to source control.
Yes it seems like a lot of work. It's a lot of work, but the payoff is also big. The ability to ensure that your changes don't break anything allows you to move your product forward faster with a better quality.
Take a look at NUnit and NDbUnit
I'm sure there are more elegant ways to address this, but if the database isn't too complex, here's a quick and dirty way:
Select all the sprocs and script to a query window.
Search for the old column name.
If you are only interested in finding the column usage in the stored procedure probably the best way will be do do a brute force search for the column name in the definition column sys.sql_modules table - which stores the definition for the stored procedures/functions.