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"
Related
Information: We are in the process of Testing our upgrade from SQL Server 2005 to SQL server 2012 on staging. In reading the documentation on features that will no longer be supported, COMPUTE (Transact-SQL) going away is going to be an issue for us.
Question: Is there any way to write out our own procedure that will take the place of the compute builtin on SQL Server 2012 that will make it seamless so when Compute is called it will function like SQL Server 2005? The alternative is we will we need to update all the SQL files, UDF's, Triggers, and stored procedures that use this built in with alternative code?
Note I have never tried to recreate a built in function before so any information on this will be very helpful for me and anyone else trying to do this in the future. Also knowing if it can be done is a plus.
Clenup: As always if this is a duplicate post indicate the link below and i will remove my post.
COMPUTE BY is not a function. I don't see how it's effects (generating additional result sets) can be replicated easily.
Replacing COMPUTE BY with a temp table and some looping should be kind of straight forward but it will be a laborious task. It's probably better to change the application so that it does not depend on multiple result sets.
I have made the recommendation of moving to SQL Server 2008 first, this will give us 4 years or so to update all the code and then we can move up to SQL Server 2012.
That sounds reasonable. By then there will be at least SQL Server 2016 so you'll have to see what other features are deleted at that point :)
This is not directly a programming question but I ask it anyway because it's related to debugging.
I wonder if it's possible to see exactly what SQL statements that are being executed within a procedure in Microsoft SQL Server Profiler?
For now I just see the procedures being called but due to complicated procedures causing a tricky bug somewhere I would like to see exactly what SQL statement being executed. So it would be nice if anyone has any tip on this.
Yes this is possible.
Add SP:StmtStarting and/or SP:StmtCompleted to the events you are tracing.
I've got a stored procedure I run from VB code in an Access 2007 database. Usually the code runs fine; however sometimes I receive the following error:
Error # -2147217900 was generated by Microsoft OLE DB Provider for
ODBC Drivers [Microsoft][SQL Server Native Client 10.0][SQL
Server]Executing SQL directly; no cursor.
I have done quite a bit of research on this and I haven't come up with much. There are two sources I've seen: one of the reasons is insufficient permissions, and the other has to do with a problem in the Stored Procedure itself. I know the permissions is not an issue. Also the stored procedure runs absolutely fine in management studio no matter how many times I run it.
Help Please!!!
Working with a colleague the problem was identified. Fundamentally the core issue was that the real problem was being obfuscated by a generic error message; in this case the "no cursor" error. The trick was to figure out what the actual error message is. Having given some thought to it a coworker changed the ODBC driver from "SQL Server Native Client 10" as noted in my post to an older MS SQL Server driver; while the newer version 10 obfuscated the error the older driver revealed the actual error which was in the stored procedure (which I had believed was not the case originally due to my own testing). So the bottom line is there are two points to take from this: first if you are having this error try the above trick to try and reveal the actual error and the second note, the real problem in this case was that the driver was hiding the programming problem.
You should work out what parameters are being passed to the stored procedure when you get this error. Print out the variables you are passing to the stored procedure object. I would pay particular attention to non-alphanumeric characters such as single quotes or escape characters.
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
I am trying to transfer 67,714,854 rows from MySQL to SQL Server using SSIS. The package times out after transferring 14,282,990 rows. I changed the time out property to 0 also, but that didn't help.
How do I resolve this issue?
I found a hacky solution to it. And that is having a limit at the end of your query. I was facing the same problem with ADO .NET connection to connect to MySQL. Although it doesn't solve the problem. It atleast get the work done.
SSIS: 2208 R2.
MySQL: 5.0
On your OLE DB Destination connection, what "Data access mode" have you selected. If you have selected "Table or view - fast load" (this is the default), then there will be a "Maximum insert commit size" specified. You can try one of two things: 1) change the commit size to a larger number; or 2) try the other data access mode "Table or vew". Since you're getting a timeout error, I suspect that option 1 may not help (since you're already getting a timeout with a smaller value), so try option 2. Although that will likely result in slower performance, it may actually complete successfully. (You could then try #Siva's approach and split the output across multiple destinations to improve performance).
(Note: I'm referring to what's available in SQL Server 2008 R2, if you're using previous versions, it may be slightly different)
If none of the above work, you could also try to create a new SSIS package from scratch by running the SQL Server Import Wizard (right-click on your database in SQL Server Management Studio and select Tasks/Import Data. Follow the wizard screens and near the end make sure you check the box to Save the SSIS package, and choose a file location to save it to. Typically, the resulting SSIS package will be a functional package (and then you can also make whatever further modifications you like to it).
Does MySQL give you the error or are you using PHP (or another language) to transfer the data and does that timeout? In the case of the latter, in PHP you can set the script timeout to infinite using this:
set_time_limit(0);
Either way, based on the information given, I'm not sure what type of database it is, but typically I would set up a cron script to transfer the data bit by bit in order to keep the load at an acceptable level. Please give more information...