I am calling the following statement from withing a Stored Proc in SQL Server 2005.
Backup Database #dbname to disk = #dest
I need to be able to store the result of the 'Backup Database' in a variable so if something goes wrong I can kick off an alert to notify someone of the failure.
How can I get that value?
You can execute the Backup Database command within a TRY block I believe. Simply add some code to email the error message in the catch block of the statement.
Related
I have create a sql agent job as follows
USE [Database]
GO
DECLARE #return_value int
EXEC #return_value = [dbo].[StoredProc_RPT_Test]
#batch_id = Null,
#StartDate = Null,
#EndDate = Null
SELECT 'Return Value' = #return_value
GO
The Stored Procedure StoredProc_RPT_Test calls another stored procedure when all parameters are null. Which inserts data into a permanent table.
I can run StoredProc_RPT_Test manually and it works fine. The data is present in permanent table. However when i run the sql agent job no results in the permanent table?
Really puzzled. Is this because iam calling two stored procedures?
Did you checked the Job log for any failure message? Also please make sure the SQL server service account have execute permission on the procedures.
Most probably SQL Server Agent doesn't have enough permissions to run your SP. Set job owner (in a dialog) to the account which has permission.
When you run the job manually you do it in your context.
The issue was SQL Server Agent has a default textsize of 1024. In my SQL Server Agent step before executing the stored procedure, I simply added the textize.
e.g.
SET TEXTSIZE 15000
EXEC dbo.yourspname #param1, #param2...
Hope this will help someone.
Try to not select returned value just print inside of procedure.
I have an execute SQL task that finds the path of the latest backup of a database and populates a variable with it (User::BackupFilePath)
I want to pass that into another task that will generate a restore database script and populate another variable to be used to restore the database.
Select (
'ALTER DATABASE [Database] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
RESTORE DATABASE [Database]
FROM DISK = ''' + **BackupFilePath** + ''' WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 5
ALTER DATABASE [Database] SET MULTI_USER
GO'
) as RestoreScript
The second part that would generate the string is however returning this error message
[Execute SQL Task] Error: Executing the query "Select 'ALTER DATABASE [xxxx..." failed with the following error: "An error occurred while extracting the result into a variable of type (DBTYPE_I4)". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I'm using Visual Studio 2008 Professional Edition
So far, it looks like you're having a simple problem: the variable you're setting, to your command string, needs to be a string datatype.
Your error message mentions DBTYPE_I4, which is a long integer:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms711251%28v=vs.85%29.aspx
Whereas what you'd save a command string into, would be a string type such as DBTYPE_STR or DBTYPE_WSTR (see the link above), which in SSIS would commonly be called DT_STR (for ASCII strings) or DT_WSTR (for Unicode strings) -- see the link below:
http://technet.microsoft.com/en-us/library/ms141036.aspx
Hope that helps...
One possible cause is the property 'ResulSet' of your second SQL Task (the restore)/
Make sure it's set to 'None'
Is it possible to shut down ms sql server management studio while a stored procedure is running, without stopping the stored procedure?
If you mean an SP you are running within SSMS then no. Obviously closing your own SSMS won't affect SP's that are running from other users on the server.
You really can't, however you can create a SQL Agent job which will execute the stored proc do you need a result set returned to you or are you updating data?
If its an update I think you're fine just running it from the agent, if not, your next simplest way to return a long running stored proc's result set would to be create an SSIS package which outputs that result set to a csv, excel doc what ever is appropriate. This package can then also be executed by the SQL Agent.
Yes you can, but you will not be able to see the result of the SP if something is returned. Once the execution is given to server the server will execute the SP not the SSMS.
I have a SQL Server 2000 database with a stored procedure that deletes a row from a specific table, given its id. When I call the stored procedure from VB.NET, it does not delete the row, but running the same script directly on the database via SSMS, it works.
Here's my chain of events:
Start SQL Server Profiler to watch all calls to the database. I have
it setup to track when stored procedure starts, completes, and even
on SQL statements start/complete within that stored procedure.
Call stored procedure via VB.NET dll.
Stop the profiler trace to avoid excessive data to dig through.
Select from table, and see that the row still exists.
View the profiler trace, which only shows RPC:Starting, SP:Starting, RPC:Completed. No inner statements are traced, which verifies why the row wasn't deleted since the delete statement never fired.
Copy/paste the EXEC call directly from the RPC:Starting trace entry from when it was called via VB.NET, into SQL Server Management Studio query window pointed to the same database with same credentials.
Start profiler again.
Execute EXEC statement from bullet 6 in SSMS.
Stop profiler.
Select from table, and see that the row GOT DELETED like it should.
View the profiler trace, which shows SP:Starting, all statements starting/completed including the DELETE statement, and SP:Completed.
Why would running it via RPC make it not execute any of the statements in the proc, but running directly acts as it should?
EDIT: Below is my VB.NET code. This is the same code we use in over 100 other places:
Dim paramRowID As New SqlParameter("#RowID", sRowID)
Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(oConn, "spDeleteRow", paramRowID)
See SqlHelper source here.
EDIT: I hate myself right now. :) SQL threw an exception "nvarchar is incompatible with image" about another parameter that I was passing NULL to. SSMS didn't worry about the type, but VB.NET did since I didn't explicitly tell it that it was of type image. Once I defined that param, it worked. I wish profiler would have told me there was an error though.
Any help would be appreciated,
Greg
That would be because SSMS does not call an RPC but a batch. There is no way in fact to call a RPC from SSMS since you cannot declare a parameter, which is what differentiate an RPC call from a batch call in TDS:
2.2.1.3 SQL Batch To send a SQL statement or a batch of SQL statements, the SQL batch, represented by a Unicode string, is copied into the data section of a TDS packet and then sent to the database server that supports SQL. A SQL batch may span more than one TDS packet. See section 2.2.6.6 for additional detail
2.2.1.5 Remote Procedure Call To execute a remote procedure call (RPC) on the server, the client sends an RPC message data stream to the server. This is a binary stream that contains the RPC name or numeric identifier, options, and parameters. RPCs MUST be in a separate TDS message and not intermixed with SQL statements. There can be several RPCs in one message. See section 2.2.6.5 for additional details.
So monitor instead for the SQL:BatchCompleted event and you'll see your SSMS statement(s).
Does the user the application is using to connect to sql have permission to execute stored procedures? That is the first thing I would verify.
A very short and straight question: I want to catch the error using try..catch and log it into a file. Is this possible in SQL Server 2008?
Any directions, help are welcome.
Yes, you can.
Just implement try catch as it's described here TRY...CATCH . Error logging can be logged either in application or in sql by writing errors to a table.
If you want to log into a file, you can do that using SQLCLR. Check the answer here
How to log in T-SQL
There're some similar questions you can check.
Logging into table in SQL Server trigger
Best Practices - Stored Procedure Logging
Another approach is to use Log4Sql
View the SQL Server error log by using SQL Server Management Studio or any text editor.
By default, the error log is located at Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ERRORLOG and ERRORLOG.n files.
Go through Viewing the SQL Server Error Log page
Like this, not exactly to file, but to eventlog, I think writing to file is only possible with CLR procedure:
BEGIN TRY
Do some error
END TRY
Begin CATCh
Declare #error nvarchar(max) = error_message()+' your data'
exec master..xp_logevent 50001, #error, 'error'
--Notify host application
RAISERROR(#error, 16, 1)
END CATCH