Database

15-Jan-09 21:33

Good Morning ALL

I want to Restore a database, i have the Following SP

Create PROCEDURE [dbo].[sp_RestoreDatabase] 

	@dbname char(32), 	-- the database name to restore as
	@filename char(32),
	@Results int OUTPUT
  
AS

set nocount on

declare @path char(256)
set @path = 'C:\DATABASES\' 	-- the location of the backuped up database file	(on the SQL Server)

execute('sp_ClearDatabaseConnections ' + @dbname) --kill the existing connections to the current Database

-- Restore the database
RESTORE DATABASE  @dbname 
FROM DISK ='C:\DATABASES\'+ @filename
WITH MOVE 'TNGoedit_Data' TO 'C:\DATABASES\'+ @dbname + '.mdf' ,
MOVE      'TNGoedit_Log' TO 'C:\DATABASES\'+ @dbname + '_log.ldf',
REPLACE,RECOVERY;
-- Was the command successful or was there a problem
if ( (select @@Error) = 0 ) begin
  SET  @Results = 1
end
else begin
   SET @Results = 0
end

When i Compile this SP i get the Following Error

Msg 102, Level 15, State 1, Procedure sp_RestoreDatabase, Line 27<br />
Incorrect syntax near '+'.

Where is my Problem

Thanks

Vuyiswa Maseko,

Few companies that installed computers to reduce the employment of clerks have realized their expectations.... They now need more and more expensive clerks even though they call them "Developers" or "Programmers."

C#/VB.NET/ASP.NET/SQL7/2000/2005/2008
http://www.vuyiswamaseko.tiyaneProperties.co.za
vuyiswam@its.co.za

Wendelius15-Jan-09 22:02

15-Jan-09 22:02

Do you have an extra comma at the end of this line:

MOVE      'TNGoedit_Log' TO 'C:\DATABASES\'+ @dbname + '_log.ldf',

The need to optimize rises from a bad design.My articles[^]

Vimalsoft(Pty) Ltd15-Jan-09 22:24

15-Jan-09 22:24

No , the Problem points on the line that uses the "+" Sign

Wendelius15-Jan-09 22:59

15-Jan-09 22:59

There was a plus on that line too, but if you double click the error, which of those lines is highlighted?

The need to optimize rises from a bad design.My articles[^]

Vimalsoft(Pty) Ltd15-Jan-09 23:01

15-Jan-09 23:01

It goes to this line

FROM DISK = @path + @filename

Thanks

Wendelius15-Jan-09 23:11

15-Jan-09 23:11

What happens if you first modify the variable and then use only it in the restore, like:

...
SET @filename = 'C:\DATABASES\'+ @filename
-- Restore the database
RESTORE DATABASE  @dbname 
FROM DISK = @filename
...

The need to optimize rises from a bad design.My articles[^]

Vimalsoft(Pty) Ltd15-Jan-09 23:25

15-Jan-09 23:25

Now it moved and Targeted the Following lines

WITH MOVE 'TNGoedit_Data' TO  @path + @dbname + '.mdf' ,
MOVE      'TNGoedit_Log' TO  @path + @dbname + '_log.ldf',

Thanks

Wendelius15-Jan-09 23:33

15-Jan-09 23:33

Seems that the problem was found so try to do the same for all variables, like:

...
SET @movetarget1 = @path + @dbname + '.mdf'
...
WITH MOVE 'TNGoedit_Data' TO  @movetarget1...

The need to optimize rises from a bad design.My articles[^]

Vimalsoft(Pty) Ltd15-Jan-09 23:41

15-Jan-09 23:41

Thanks i have Change the SP to look like this and it compiled fine ,

Create PROCEDURE [dbo].[sp_RestoreDatabase] <br />
<br />
	@dbname char(32), 	-- the database name to restore as<br />
	@filename char(32),<br />
	@Results int OUTPUT<br />
  <br />
AS<br />
<br />
set nocount on<br />
<br />
declare @path char(64)<br />
declare @dbmdf char(64)<br />
declare @dbldf char(64)<br />
set @path = 'C:\DATABASES\' 	-- the location of the backuped up database file	(on the SQL Server)<br />
	<br />
execute('sp_ClearDatabaseConnections ' + @dbname) --kill the existing connections to the current Database<br />
<br />
SET @filename = 'C:\DATABASES\'+ @filename<br />
set @dbmdf = 'C:\DATABASES\' + @dbname + '.mdf'<br />
set @dbldf = 'C:\DATABASES\' + @dbname +'_log.ldf'<br />
-- Restore the database<br />
RESTORE  DATABASE @dbname <br />
FROM DISK = @filename<br />
WITH MOVE 'TNGoedit_Data' TO  @dbmdf ,<br />
MOVE      'TNGoedit_Log' TO  @dbldf,<br />
REPLACE,RECOVERY;<br />
-- Was the command successful or was there a problem<br />
if ( (select @@Error) = 0 ) begin<br />
  SET  @Results = 1<br />
end<br />
else begin<br />
   SET @Results = 0<br />
end

and i tested it like this

DECLARE @Results INT
EXEC [dbo].[sp_RestoreDatabase] 'oBookingUFS','oBookingUFS',@Results out

and i got the Following Error

<br />
Msg 3234, Level 16, State 2, Procedure sp_RestoreDatabase, Line 27<br />
Logical file 'TNGoedit_Data' is not part of database 'oBookingUFS                     '. Use RESTORE FILELISTONLY to list the logical file names.<br />
Msg 3013, Level 16, State 1, Procedure sp_RestoreDatabase, Line 27<br />
RESTORE DATABASE is terminating abnormally.

Thanks

Wendelius16-Jan-09 8:52

2 basic transaction issues

16-Jan-09 8:52

Are you sure that this is the logical file name 'TNGoedit_Data' or should it be for example 'TNGoedit'

You can verify the logical names using RESTORE FILELISTONLY[^]:
RESTORE FILELISTONLY
FROM DISK = 'C:\DATABASES\oBookingUFS';

The need to optimize rises from a bad design.My articles[^]

George_George15-Jan-09 20:21

15-Jan-09 20:21

Hello everyone,

Two basic questions about transactions,

1. For single SQL insert/update/delete statement, are there any needs or benefits to wrap into a transaction?

2. I wrote T-SQL like this,

BEGIN TRY
Begin Transaction
...
commit
END TRY
BEGIN CATCH
rollback
...
END CATCH

my question is, is it a must to call commit explicitly just before end try statement? Any means to commit transaction automatically after end try statement?

regards,
George

Wendelius15-Jan-09 20:57

15-Jan-09 20:57

George_George wrote:
For single SQL insert/update/delete statement, are there any needs or benefits to wrap into a transaction

It's always inside a transaction. Either implicit or explicit. If you don't want to be able to rollback the operation then it wouldn't matter, if you have logical error handling etc, then explicit transaction would be needed.

George_George wrote:
is it a must to call commit explicitly just before end try statement? Any means to commit transaction automatically after end try statement

Basically commit point canbe anywhere, even at client side. However if you explicitely start a transaction, you have to explicitely end it. If you don't execute commit, database will roll back the transaction at the end of the session (unless other transaction handling is occurring after this transaction).

The need to optimize rises from a bad design.My articles[^]

George_George15-Jan-09 21:37

15-Jan-09 21:37

Thanks Mika,

1.

"If you don't want to be able to rollback the operation then it wouldn't matter, if you have logical error handling etc, then explicit transaction would be needed." -- I am confused. Could you show me a sample about the benefit please? My detailed confusion is even if I do not start transaction explicitly, I could still catch the error and handles it. Smile | :)

2.

"Basically commit point canbe anywhere, even at client side." -- what do you mean client? No matther what kinds of API you are using or even using Management Studio directly, I think we are all "client" of database engine.

regards,
George

Wendelius15-Jan-09 21:54

15-Jan-09 21:54

George_George wrote:
if I do not start transaction explicitly, I could still catch the error and handles it

Yes you can if the error is 'technical' and SQL Server sees it as an error. But what happens if the error is logical. Consider following imaginary scenario.
- insert into a table
- check that some business rule apply
- if business rule is violated, undo the insert
The previous is very simple and it wouldn't be a problem to just change the order of the operations. However, this is not always the case.
Since there's typically no harm in using explicit transactions, personally I've decided to use them always.

George_George wrote:
what do you mean client? No matther what kinds of API you are using or even using Management Studio directly, I think we are all "client" of database engine.

I meant a scenario where your try catch is inside a stored procedure and a client application (whatever it is) calls the procedure. Ending point can be at the calling side so the procedure is actually just a part of a bigger transaction scope.

The need to optimize rises from a bad design.My articles[^]

George_George15-Jan-09 22:42

15-Jan-09 22:42

Thanks Mika!

"I meant a scenario where your try catch is inside a stored procedure and a client application (whatever it is) calls the procedure. Ending point can be at the calling side so the procedure is actually just a part of a bigger transaction scope." -- so in this scenario, client code (e.g. ADO.Net) starts the transaction, but what is the practice of writing store procedure code in this way? Do we also need try-catch and begin transaction/rollback/commit code in store procedure?

BTW: I have this confusion because I as a store procedure developer -- not sure whther client will start another transaction or not. So, how could I write code in store procedure which could handle both client starts transaction or store procedure self-start transaction?

regards,
George

Wendelius16-Jan-09 9:07

16-Jan-09 9:07

How the transaction scope is defined is a matter of opinion. I think most people use the logic that stored procedure starts and ends the transaction. However, there are downsides especially if rollback is executed because in that case the whole transaction is rolled back, even if it's started outside the stored procedure.

So this means that you actually cannot decide alone what transaction scope will be used. The application may be affected by your decisions. You could use @@TRANCOUNT to investigate if transaction is started outside the procedure and in the logic of your stored procedure you would execute rollback based on the initial transaction count.

There's a very good article you should read: http://www.codeproject.com/KB/database/sqlservertransactions.aspx[^]

The need to optimize rises from a bad design.My articles[^]

Ashfield15-Jan-09 21:02

Ashfield

15-Jan-09 21:02

George_George wrote:
1. For single SQL insert/update/delete statement, are there any needs or benefits to wrap into a transaction?

No, there are no benefits in this case.

George_George wrote:
Any means to commit transaction automatically

This tells you all about it MSDN[^]

Bob
Ashfield Consultants Ltd
Proud to be a 2009 Code Project MVP

George_George15-Jan-09 21:24

15-Jan-09 21:24

Thanks Ashfield!

Two more comments/questions after learning,

1.

I want to confirm with you that if we call begin transaction, do you mean the only way to commit transaction is to explicit call commit?

2.

If I do not use begin transaction explicitly using begin transaction statement (the default behavior is to auto-commit for each successful statement), no other configurations to disable auto-commit for successful each statement -- means we could have chance to commit later in a batch manually explicitly?

regards,
George

Ashfield16-Jan-09 1:17

Ashfield

16-Jan-09 1:17

George_George wrote:
I want to confirm with you that if we call begin transaction, do you mean the only way to commit transaction is to explicit call commit?

Correct

George_George wrote:
means we could have chance to commit later in a batch manually explicitly?

No - the default autocommit will have happened

Bob
Ashfield Consultants Ltd
Proud to be a 2009 Code Project MVP

George_George15-Jan-09 21:38

15-Jan-09 21:38

Thanks Bob,

Sorry one more question, there are 3 modes, autocommit, explicit and implicit. How to disable/enable implicit mode? Smile | :)

regards,
George