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
Related
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.
I have a SQL Azure database. I'm able to export the Database using Tasks > Export Data Tier Application. This is successful.
I then try to use Import Data Tier Application in my local SQL server and I get the following error:
Could not import package. Warning SQL0: A project which specifies
Microsoft Azure SQL Database v12 as the target platform may experience
compatibility issues with SQL Server 2008. Warning SQL72012: The
object [db_Data] exists in the target, but it will not be dropped even
though you selected the 'Generate drop statements for objects that are
in the target database but that are not in the source' check box.
Warning SQL72012: The object [db_Log] exists in the target, but it
will not be dropped even though you selected the 'Generate drop
statements for objects that are in the target database but that are
not in the source' check box. Error SQL72014: .Net SqlClient Data
Provider: Msg 102, Level 15, State 1, Line 1 Incorrect syntax near
'CREDENTIAL'. Error SQL72045: Script execution error. The executed
script: CREATE DATABASE SCOPED CREDENTIAL [databasenameAzureStorageCredential]
WITH IDENTITY = N'SHARED ACCESS SIGNATURE';
I have SQL Server Management Studio 14.0.17289.0 and everything is up to date.
I have read different posts on Stack overflow and done some googling but unsure the best way to move forward. How can I solve this?
It seems like there is a compatibility mode differences in your local SQL server DB and Azure SQL server DB. Check your compatibility level and if it is mismatched here is the resource to solve that. The error was because you use SSMS version 'X' to generate the bacpac against Azure SQL version 'Y'. Try to generate the same bacpac using SSMS version 'Y' and it works for me.
Please download the latest version of SQL Server Management Studio from here to have the best user experience with Azure SQL Database. SSMS v14 is too old. The current version of SSMS is v17.9.
Remove (drop) the database scoped credential named "databasenameAzureStorageCredential" before exporting the database. The following query should give you a list of credentials created.
SELECT * FROM sys.database_scoped_credentials
In general, you need to remove references to external sources before exporting your database.
use counts
select *
from tools..create_output 'week16_em_final','counts',',opt_in,email,ip,sourceur','\\Sqlsrvr\f\Orders\misc\EliteMate\'
All I'm trying to do is export some data from one of our databases.
Here is the error that I'm getting:
Msg 102, Level 15, State 1, Line 6
Incorrect syntax near 'week16_em_final'.
Any idea why it wouldn't gather the data and export this small file?
Thanks for any and all help, I'm a newbie to SQL, so, sorry in advance.
It can be done if you have Import and Export Wizard:
You can enter your password if you choose SQL Server Authentication option also choose your Server name to a Source Server then `Database'
You can enter your password if you choose SQL Server Authentication option also choose your Server name to a Destination Server then Choose then `Database'
You can click edit mappings as an option.
Click Next or Finish Button
First, you are using very unsupported software. You mention stored procedure - which we must guess is named create_output. If that is true, you can't use this syntax. You execute a stored procedure, you don't select from it. Example:
execute tools.dbo.create_output 'week16_em_final', 'counts',',opt_in,email,ip,sourceur','\\Sqlsrvr\f\Orders\misc\EliteMate\'
Note that I added the schema name (assumed to be dbo) - don't start bad habits. However, that string of parameters looks very strange as you formatted it so there will likely be other errors as well. If this is your first attempt, you should ask a colleague for help.
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';
We currently have an issue with our MSSQL 2005 database. We've recently undergone a migration from windows server 2003 to 2008. SQL Server has remained as 2005. I'm using SQL Server Management Studio to work on.
All the tables in the database follow the format: [SCHEMA].[TABLE_NAME]
When I enter the SQL:
SELECT * FROM [table_name]
I get the error message: Invalid object name '[table_name]'.
If I type in:
SELECT * FROM [schema].[table_name]
This works fine. The username we log into the database with owns the schema which is prepended to all the table names.
The problem is, we have 3rd party companies which have software which exports data from the database. 2 companies have now tried to run their exporters, however are getting the error 'Invalid object name'. The software is logging in with the username which owns the schema.
My question is exactly the same as this one I've found on the internet:
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=99802
However the answer on that question seems to be full of keywords rather than actual sentences which makes it very hard to understand.
If anyone could help, it'd be greatly appreciated.
Many thanks
Phil
Set the default schema for the 3rd party's username to the schema their un-prefixed references should point to:
ALTER USER foo WITH DEFAULT_SCHEMA = [bar];
(This is different from owning the schema.)
And tell them to write software correctly. In SQL Server you should always be specifying the schema name, even if you always use dbo.