We have a strange problem in our team. When a developer is using Eclipse in Debug mode, SQL Server 2005 blocks other developers from accessing a stored procedure. Debug session typically involves opening Hibernate session to persist an entity which could be accessing a stored procedure used for Primary key generation. Debugging is done in business logic code and rarely in JDBC stored procedure call.
Is there any way to configure SQL server or the stored procedure so that other developers are not blocked?
I don't know for sure how Eclipse is doing the locking, but it sounds like you need to get each developer who will be debugging their own copy of the database.
Related
I'm trying to find a bug on a store procedure(SQL server) that gets executed from a console application coded in C#. Is there a way I can do some sort of breakpoints into the Store Procedure scripts and find how the data gets processed into the store procedure in real-time?
I know that you can debug a simply Stored procedure on Visual Studio. But what I want to do it's to debug it in real-time with the console application.
Dependent on which version of SQL Server you are using you will want to use either SQL Server Profiler or Extended Events, see Quick Start: Extended events in SQL Server and SSMS XEvent Profiler.
I develop a software system that runs on multiple computers that connect to a centralized database.
At this point in time, all SQL queries are inline with the applications source code. I would like to start migrating these into stored procedures.
If I need to make a change to a stored procedure that will require a software change, how can I synchronize the updates? For example: I change sp_SelectRecordByID and publish an update for the software. Immediately, all running software versions will receive an error upon running sp_SelectRecordByID. Once they crash and the update is received, all is good.
How do I prevent this scenario?
I've come up with a few ideas:
Make a new stored procedure and let the old one die off slowly
Add version checking to the stored procedure. This is highly undesirable.
Are there more effective methods or am I stuck with these options?
From what I understood this is more of a deployment issue. The way I see it there are couple options.
If you can deploy SQL Server and application changes simultaneously (or at least near to that) then you can just publish both at the same time but I guess it depends on the system.
Can you do this over the weekend when there is no risk of applications crashing?
Do you deploy the new application version to all users at once? If yes then you can just create new SP first, deploy new application version and then delete old SP.
Anyway, hope this helps. If not, please provide more details on number of servers, number of client applications and such…
Are you using Visual Studio? You can keep your stored procedures in a database project and have version control this way.
More info in here: http://msdn.microsoft.com/en-us/library/xee70aty.aspx
Scenario: System in a VM in Azure using MVC and a SQL Database (not in the VM) working under normal conditions for 2 or 3 months. Suddenly, stored procedures called from my MVC web app or SQL Management Studio return Time Out. Queries like Select * from Table work perfect.
EDIT: Timeouts while executing Alter or Create SP queries happened too.
No proper solutions or explanations found.
Workaround: Restore old backup in a new SQL Database and change the connection string to the new Database. While the system is running in the backup, try to backup the database with issues (first close all connections to that DB like Management Studio). It may take some time and some retries. After the backup is done, restore it in a new DB and change back the connectionString. You will lose a few minutes of data and some downtime but you will have your system working again in Azure.
Any ideas about this issue in the Stored Procedures in Azure?
At first glance, this smells like a parameter sniffing issue; it is probably not related to Azure.
Check this thread for details on what the issue is, and how to resolve it: Parameter Sniffing (or Spoofing) in SQL Server
If I use a web application Web Data Administrator and I edit the stored procedures SQL query, does it recompile on it's own? (new to SQL Server and this side of the database development)
MSSQL Server does maintain a cache of query plans, but this is not the same as compiled code.
The SQL Server manages this cache and can be the source of some pain if it caches a plan that is non-optimal. Though this has happened to me less than 5 times in 15 years (and that seemed to be a problem with a particular server), its best to let SQL server handle this and not touch it.
You can force SQLServer to recompile by supplying the WITH RECOMPILE option. Same caveat applies, unless you have a substantial reason to, DONT.
SQL is a scripting language, which means the code you write is not compiled. Rather, it is stored on the server to be used later.
When you edit a stored procedure, you can execute an ALTER script, or a DROP then CREATE script. This sends the text in your Web Data Admin (or SSMS) window to the server, issuing a command that tells the server to store this new query as a procedure for later use.
So, in short, yes, if you execute an ALTER script.
Whilst working on a SQL Server 2008 database project in Visual Studio 2010 I added a new parameter to an existing stored procedure definition. When I built the project it failed to detect that references to the sproc elsewhere in the project did not have enough parameters. It even let me deploy the project.
Is this the way it's meant to behave or have I forgotten to tick a box somewhere?!
Sam : )
Database projects do not detect problems with procedure/function parameters. Also, you will notice you can delete the offending procedure/function from your project all together and it won't fail.
In my case, I use an external tool for managing programmability, so not failing the build because of missing procs is a plus.
If you want to validate your procedures and functions you can write a scipt that will execute all your stored procedures with using "SET FMTONLY ON". The procedure will be compiled, but no permanent changes will be made to the DB during execution. You can't use this with procedures that use temporary tables (#table syntax).
That's how Microsoft does it in Visual Studio to determine what the output of your stored procedure should be.
Unless you re-run the code generation wizard (by deleting the sproc in the VS Server Explorer then dragging it back in) your project doesn't know that the database has changed. You may get runtime errors but not compile errors.
If it doesn't know about any changes it will compile normally. So yes, it's supposed to behave that way.