Can't restore SQL Server database to another server - sql

I'm trying to migrate databases from an old, dying server, to the new one.
All over the internet, I found two handy scripts by Andrew Morgan, for saving and restoring databases. The backup part works well; I get my db.bak on my local pc by sharing the folder over the network and having the script backup the db to the unc path.
Unfortunately, the restoring part won't work, and I don't know why (and my senior DEV doesn't know either, and he's the one knowing SQL aorund here).
I'm calling it this way:
Restore-SQLdatabase -SQLServer "NEWSERVER\MSSQLSERVER" -SQLDatabase "DBToMigrate" -Path "C:\Backup\DBToMigrate.bak" -SQLusername "sa" -SQLpassword "IMAPLAINTEXTPASSWORD"
sa has complete power over the database.
It fails with the following message:
Attempting to connect to the Specified SQL server: Success
WARNUNG: An Exception was caught while restoring the database!
WARNUNG: Ausnahme beim Aufrufen von "ExecuteNonQuery" mit 0 Argument(en): "Incorrect syntax near '‘'.
Incorrect syntax near the keyword 'with'. If this statement is a common table expression, an xmlnamespaces clause or a change tracking context clause, the previous statement must be terminated with a semicolon."
WARNUNG: attempting to recover the database
The part in question is:
ALTER DATABASE $SQLDatabase
SET SINGLE_USER WITH ROLLBACK IMMEDIATE
RESTORE DATABASE $SQLDatabase
FROM DISK = '$path'
WITH REPLACE
When it gets executed, the scipt gets the exception.
I tried putting a CREATE DATABASE $SQLDatabase in front of the ALTER part, but then it says something along the lines of "that database name already exists", after creating that db.
Also, when omitting the altering part and changing that part to
RESTORE DATABASE $SQLDatabase FROM DISK = '$path' WITH REPLACE
It says something about the database files, giving me the path on the old server (which I'd like to be completely irrelevant, but it seems there may be my next problem), cannot be found (of course, since I'm on my local machine now, which doesn't have those).
I'm doing it with a script, because there are around 15 databases we need to migrate, and also because I want to learn how to do this stuff without just using the SSMS wizard.
Update: I changed the apostrophes to normal ones, that was indeed the mistake. Now I just need to get the file name of the db files so I can MOVE them to the new server.

All you need is to write a new destinations to your files, you can check the syntax of RESTORE here: RESTORE Statements (Transact-SQL)
And your code will be like this:
RESTORE DATABASE AdventureWorks2012
FROM AdventureWorksBackups
WITH MOVE 'AdventureWorks2012_Data' TO
'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf',
MOVE 'AdventureWorks2012_Log'
TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf';

Related

SQL Server 2017 database downgrade to SQL Server 2014 (the target is in a Virtual Machine)

I've been dealing for trying to migrate a really big database to an earlier SQL Server with multiple ways, I started doing a .bak file, but I found that it is not compatible and it should be the same SQL Server version.
Then I chose the task - generate Script, to create a .sql file with all schema and data, but the file was 24gb big! Even though the file was really big by using the sqlcmd I managed to execute it. But it never finished executing successfully, it threw multiple types of errors, like:
Msg 156, Level 15, State 1:
Incorrect syntax near the keyword '...'
Msg 105, Level 15, State 1
Unclosed quotation mark after the character string
Then I found this comment with 2 solutions https://stackoverflow.com/a/27623706/3192041, I tried the first one but still throwing the second error, I tried the second one and It worked! everything was now running smoothly, but then I got another error...
This error:
Sqlcmd: Error: Internal error at ReadText (Reason: An attempt was made
to move the file pointer before the beginning of the file).
So now the issue has something to do with sqlcmd command??
Should I continue trying to migrate the database with the generated script? is there a better way of this and making it compatible with an earlier SQL Server version?
Things to clarify
I first created a script only with schema information, but when I tried to generate a separate script for data only the SSMS was throwing an error. So with this way I can't or I don't know how to export all data with an easy way. I know you could export data for each of the tables, but the database has more than 200 tables and this is not viable.
Also the script takes more than one hour, and maybe a lot more than that time if the process would finish correctly.
Finally after also trying with a bacpac file, that also didn't let me to create because of a bunch of errors of windows users, external object references, and more...
The best answer to solve this, is by creating a .dacpac file. The dacpac file from SSMS 2012 to the latest versions, you can now include the data of all your tables.
And to solve the incompatibility issue, you can use the AllowIncompatiblePlatform property to allow deployment to different versions of SQL Server when publishing to the target server.
so first you need to extract using the SqlPackage.exe from your bin folder of the sql server, in my case this is the folder: C:\Program Files (x86)\Microsoft SQL Server\130\DAC\bin
then run the command with the Extract action:
SqlPackage /Action:Extract /SourceDatabaseName:"<database-name>" /SourceServerName:"<server-name>" /SourceUser:"sa" /SourcePassword:"<password>" /TargetFile:"<dacpac-file-path>" /p:ExtractAllTableData=True
Then in the other server run this command in correct bin folder of the SqlPackage.exe program:
SqlPackage /Action:Publish /SourceFile:" <dacpac file path>\filename.dacpac" /TargetDatabaseName:"<database name>" /TargetServerName:"<ServerName>" /TargetUser:"<username>" /TargetPassword:"<password>(if needed)" /p:AllowIncompatiblePlatform=true /p:CreateNewDatabase=true
And If you want to create the database from scrath.
/p:CreateNewDatabase=true
I hope this helps anyone with this problem, with big databases, and importing from a bigger sql server version.

SQL Server 2014 - Incorrect syntax near the keyword 'tran'

I am trying to install a stored procedures. When I run the query I get Incorrect syntax near the keyword 'tran'
The 'tran' keyword is used in dump tran master with no_log
It would be helpful if anyone help me overcome this issue.
You're getting a syntax error because TRAN isn't a SQL keyword and isn't valid for the syntax of DUMP. See https://technet.microsoft.com/en-us/library/ms187315(v=sql.90).aspx. To use DUMP properly, it's either DUMP DATABASE or DUMP TRANSACTION
Note that per the above link, DUMP is flagged as deprecated and only exists for backwards compatibility. It will go away in the future. You should be using BACKUP (probably BACKUP LOG in this case) instead.
From some SQL Server 2005 documentation on DUMP, I found the following:
The DUMP statement is included for backward compatibility. This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Instead, use BACKUP.
I bet that DUMP has already been removed from SQL Server 2014.

MDF File not Opening in SQL Server

My database file of SQL Server 2012 cannot be opened, it causes the following error.
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:903; actual 0:0). It occurred during a read of page (1:903) in database ID 6 at offset 0x0000000070e000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\inventoryDB.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
I also checked it by using
DBCC CHECKDB(inventoryDB, REPAIR_ALLOW_DATA_LOSS)
But the result is given below
DBCC results for 'inventoryDB'.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'inventoryDB'.
Is any possibilities to recover my data from that database file? I am also done many methods in many of the sites. But it not working and shows same error messages.
Do you have any mdf backup after this error occurred? If yes, you should try to create a table and restore from it using your backup.
Or try reading this article:
https://support.microsoft.com/en-ph/kb/2152734
See if it helps with your error.
You've got corruption in your DB. Either the DB was corrupt before you tried working it and you didn't notice, or it was damaged in the work.
Here. We have few options.
Solution one - If you have a backup file, You can restore your database.
Solution two - If you do not have a backup file, you can use DBCC CHECKDB to repair it. (Resource : https://www.stellarinfo.com/blog/how-to-repair-sql-database-using-dbcc-checkdb-command/)
Thanks :)

Syntax error when trying to change schema in SQL Server database

I am trying to rename the schema for a dozen tables in an old database on SQL Server 2005. I'm using SQL Server Management Studio Express version 9.0. Based on detailed advice found here, as well as several forums on other sites, I've been trying this straightforward command:
ALTER SCHEMA newschemaname TRANSFER oldschemaname.table1
I consistently get this error:
Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'SCHEMA'
It's the same whether I run it directly in the "New Query" window or build it into a stored procedure.
The database's owner is "SA," dating back to when my web host (the physical server's owner) first set up this database years ago. This makes me think there might be a permissions issue, or some obscure mismatch between the owner name and the login I'm using. But if that was true, I'd expect the error to tell me I don't have rights to execute that command.
Is there some obvious syntax error I'm missing, or do I need to delve deeper into the ownership and permissions to get the rights to fix this?
New Schema name needs to be in brackets otherwise it will fail
Example statement:
ALTER SCHEMA [NewSchemaName] TRANSFER dbo.Tracking

Restoring a database using vb.net

Can anyone help me how to restore a database from vb.net,I tried to restore using stored procedure by taking retore template script from sql server2005. but there is error "the database is already in use please use a master database.."
I assume you used the same connection string you usually use to connect to the database you are actually restoring.
From you error message, I'd say you should create your connection to the server with a different InitialCatalog parameter (the error message indicates you should use "master").
The other option is to stick a "USE master" at the beginning of the script. Here is a small description of the USE statement.
From the error it doesn't look like there is an actual VB.net programmatic error.
It seems like the problem lies on the database restoration stored procedure.
Before restoring database, make sure that
• Your connection is not using the database you are restoring - That is one of the possible reasons for that error, "the database is already in use please use a master database.."
• Other connections to the target database should be closed off - Close all connection to it.
Denis Troller has mentioned "USE master" and make sure that your script has that statement as the very "first" statement in your restore batch script.
I just wrote this in my project so I thought I'd share my method.
I'm calling the backup and restore by firing the SQL at the server using an SqlCommand.CommandText and setting the SqlParameters for database and filename as follows:
Simple backup:
BACKUP DATABASE #dbName
TO DISK=#fileName
WITH FORMAT
Then restore it using :
USE master
RESTORE DATABASE #dbName
FROM DISK = #fileName
There are plethora of options on the BACKUP and RESTORE commands but I just wanted a quick sledge-hammer approach and this works nicely.
Thanks to Denis for the 'USE master' tip, which just fixed my 'in use' error!