I would like to recommend

1, Check fillfactor, and reset it if necessary;

2. Reindex your table;

3. Run DBCC SHINKDB.

You guys are right. I used the old version of stored procedures for SQL 2000 in SQL 2005.

Now, the problem is solved.

Many thanks for your input.

Did you try the command,

RESTORE DATABASE yourDB WITH RECOVERY

?

As long as the files are in the same raid, there is no difference in performance.

Remove the line related to the path of log file.

After running your script, a new log file will be automatically created in the same folder of the data file.

BACKUP DATABASE [database2] TO DISK = '\\myServer\C$\myDB.bak'

It is also good for SQL 2000. I did it before.

It is really a case-by-case question. Here is a link for your reference. May it help.

http://msdn.microsoft.com/en-us/library/aa933139(SQL.80).aspx

I would like to say there is no issue on your SQL Server. You may check your application server and see whether or not the setting there is correct.

The answer is YES. Use network path in your backup command.

How about using linked server or OPENQUERY technique?

SQL 2005 Express edition does not provide built-in functions in SQL Agent to manage jobs as far as I know. However, we can use the third party tool to implement...

Start the server with the parameters /f /T3608, then, run this:

ALTER DATABASE mssqlsystemresource MODIFY FILE (NAME=data, FILENAME='x:\myDir\mssqlsystemresouce.mdf');

GO

ALTER DATABASE mssqlsystemresource MODIFY FILE (NAME=log, FILENAME='y:\myDir\mssqlsystemresouce.ldf');

GO

Reference the following link:

http://msdn2.microsoft.com/en-us/library/ms345408.aspx

Is there any other log backup running?

To check whether or not there is any other application running, you may try the following commands,

sp_who2 active

DBCC OPENTRAN

Did you provide new path for the ldf file?

By the way, would it better to post your question in SQL 2005 folder since your question is SQL 2005 related?