I need to get each statement of given SQL Server stored procedure.
To achieve this, I generate execution plan XML and look for "StmtSimple" nodes in query.
This approach is quite slow for large procedures.
Is there any way that I can get every single statement of the procedure without generating XML execution plan?
When you have the text of a stored procedure, you can perform a full parse on it using the TransactSql ScriptDom. If you just want to get each statement, it's possible to do that using this method.
However, I'm not convinced that it would actually perform much better than using the method you are using now. It's just another option to try.
Edit -> The ScriptDom is part of the SQL Server 2012 Feature Pack, and is contained in the 'SqlDom.msi' install.
Related
As question states:
Within powerBi there from the 'Get Data from SQL Server' -> connecting to the SQL Server
there are two options import and advanced. With Advanced, you can write a sql query to get the data or the default is import. This shows all the tables on the server and you can just ETL from a click.
What is the real difference?
If you are comfortable writing your own T-SQL select statement, you can use it to bypass the Power Query editor and send your desired statement straight to the SQL database. That is also handy if you have code already written out from a previous query or project, which you can just paste into the Advanced query window.
If you use the Power Query Editor to build you query step by step, you have a better visualisation about what data is returned by the previous step(s), and you can apply data manipulations after sighting the data.
Power Query uses query folding, which means that your individual steps are analysed and then translated into the most efficient SQL code before it is sent to the server.
That means that even if you don't speak T-SQL very well, you can still build efficient queries with the Query Editor, and if you feel you are an accomplished T-SQL developer, you can shortcut the Query Editor steps altogether. Of course that means that it is also possible to use "Advanced" and write clunky, inefficient T-SQL that performs slower than going through the Query Editor steps would.
In the end, it comes down to preference and familiarity. A seasoned DBA might just quickly write out a Select statement, a SQL rookie might prefer to click a few ribbon commands instead. The result can be identical in returned data and performance.
I'm not sure if a stored procedure is the correct path here so first, I'll explain what I need to accomplish.
I need to query one table with a variable as such:
SELECT *
FROM db.partList
WHERE column1 = 'order_no';
Then, I need to query another table as such:
SELECT [serial_no]
FROM db.resultsList;
Finally I need to iterate through the results of the above, and return the first [serial_no] from db.partList that is not in the list produced.
The original programmer was doing this in a way that was blowing up the customer's network unnecessarily. There shouldn't be any reason this can't be done locally. Now I'm here to clean it up.
Thanks in advance.
So my questions are, would this be correct use of a stored procedure? If so, could someone perhaps give me some sample code to start working with? I don't often have to dive that deep into SQL Server.
This is SQL Server 2012.
I've got some example code of how I would do it in other languages if needed. I'm just not familiar enough with stored procedures to do this quickly.
I'm providing maintenance support for some SSIS packages. The packages have some data flow sources with complex embedded SQL scripts that need to be modified from time to time. I'm thinking about moving those SQL scripts into stored procedures and call them from SSIS, so that they are easier to modify, test, and deploy. I'm just wondering if there is any negative impact for the new approach. Can anyone give me a hint?
Yes there are issues with using stored procs as data sources (not in using them in Execute SQL tasks though in the control flow)
You might want to read this:
http://www.jasonstrate.com/2011/01/31-days-of-ssis-no-more-procedures-2031/
Basically the problem is that SSIS cannot always figure out the result set and thus the columns from a stored proc. I personally have run into this if you write a stored proc that uses a temp table.
I don't know that I would go as far as the author of the article and not use procs at all, but be careful that you are not trying to do too much with them and if you have to do something complicated, do it in an execute sql task before the dataflow.
I can honestly see nothing but improvements. Stored procedures will offer better security, the possibility for better performance due to cached execution plans, and easier maintenance, like you pointed out.
Refactor away!
You will not face issues using only simple stored procedures as data source. If procedure is using temp tables and CTE - there is no guarantee you will not face issues. Even when you can preview results in design time - you may get errors in a run time.
My experience has been that trying to get a sproc to function as a data source is just not worth the headache. Maybe some simple sprocs are fine, and in some cases TVFs will work well instead, but if you need to do some complex operations there's no alternative to a sproc.
The best workaround I've found is to create an output table for each sproc you need to use in SSIS.
Modify the sproc to truncate the new output table at start, and to write its output to this instead of (or in addition to) ending with a SELECT statement.
Call the sproc with an Exec SQL task before your data flow.
Have your data flow read from the output table - a much simpler task.
If you want to save space, truncate the output table again with another Exec SQL. I prefer to leave it, as it lets me examine the data later and lets me rerun the output data flow if it fails without calling the sproc again.
This is certainly less elegant than reading directly from a sproc's output, but it works. FWIW, this pattern follows the philosophy (obligate in Oracle) that a sproc should not try to be a parameterized view.
Of course, all this assumes that you have privs to adjust the sproc in question. If necessary, you could write a new wrapper sproc which truncates the output table, then calls the old sproc and redirects its output to the new table.
Do linq generated queries get cached effectively by SQL Server 2008?
or is it better to use stored procedures with linq or what about a view and then using compiled linq queries... opinions?
cheers
emphasis here is on "effectively", and or is it better....
ie. views are cached well by sql server, and then using linq on the view....
On top of the answers already given according to Damien Guard there's a glitch in the LINQ to SQL and EF LINQ providers that fails to set the variable lengths consistently for queries involving string parameters.
http://damieng.com/blog/2009/12/13/sql-server-query-plan-cache
Apparently it's fixed in .NET 4.0.
In the past I've written stored proc's in place of LINQ queries, mainly for complex reporting-like queries rather than simple CRUD but only following profiling of my application.
L2S simply passes queries on to SQL Server 2008. So they will get cached, or not cached, like any other query submitted by any other process. The fact that a Linq query is compiled has no impact on how SQL Server processes the query.
Queries that LINQ generates are normal SQL queries like your own hand-crafted SQL queries, and they follow the same rules: if the query text is identical (down to the last comma and whitespace) than a query text before, chances are its query execution plan might have been cached and thus able to be reused.
The point is: the query text has to be absolutely identical - if even a single whitespace is different, SQL Server considers it a new query and thus will go through the full process of parsing, analysing, finding a query plan and executing it.
But basically, yes - queries sent off by LINQ will be cached and reused - if they meet those criteria!
What is a dynamic SQL query, and when would I want to use one? I'm using SQL Server 2005.
Here's a few articles:
Introduction to Dynamic SQL
Dynamic SQL Beginner's Guide
From Introduction to Dynamic SQL:
Dynamic SQL is a term used to mean SQL code that is generated programatically (in part or fully) by your program before it is executed. As a result it is a very flexible and powerful tool. You can use dynamic SQL to accomplish tasks such as adding where clauses to a search based on what fields are filled out on a form or to create tables with varying names.
Dynamic SQL is SQL generated by the calling program. This can be through an ORM tool, or ad-hoc by concatenating strings. Non-dynamic SQL would be something like a stored procedure, where the SQL to be executed is predefined. Not all DBA's will let you run dynamic SQL against their database due to security concerns.
A dynamic SQL query is one that is built as the program is running as opposed to a query that is already (hard-) coded at compile time.
The program in question might be running either on the client or application server (debatable if you'd still call it 'dynamic') or within the database server.