This happens frequently to me, SQL Server doesn't recognize my tables.
I tried to refresh the database, also tried to refresh the intellisense. But nothing worked!
Could anyone help please?
You can preface the code with
USE Sales_DB
And it will always start with that database.
Can you ensure that you are not running this against the "master" database? When setting up a user, if a default database is not specified, when you connect using SSMS it defaults to master.. change the db or use the use[your database] statement before you run any other queries.
Related
I'm following this tutorial on Microsoft Docs. I've reached the part where I use the "Data Migration Assistant", but after selecting the target Azure database and clicking "Next", I get the following error:
An unexpected error occurred.
Current principal does not have CONTROL permission on securable AzureDatabaseName of class DATABASE.
I'm using the only user of the Azure SQL server - the server admin, which should have all permissions. I've verified that the user is 'db_owner' by using IS_ROLEMEMBER.
Am I missing something?
I had the same issue. This seems to be a bug in Azure SQL databases. If you have dots in the database name it does not work. I replaced the dots with slashes and it worked for me.
You do not need to recreate the database. A rename worked fine for me:
You have to make sure, that no-one else is using the database!
Connect to master table and execute the following script on the Azure SQL Server:
USE master;
GO
ALTER DATABASE [my.database]
Modify Name = [my-database] ;
GO
Here is a link on how to rename Azure SQL databases:
https://learn.microsoft.com/en-us/sql/relational-databases/databases/rename-a-database
Also make sure to create a firewall rule for your incoming connection. This error can be a bit of a red herring.
I deleted everything - the database, the sql server, and the resource group. Then I recreated everything using the same names, except the database name - which previously contained dots - and this time the migration tool worked. I guess I just encountered some bug.
if you have dots in target database name, you have to remove or replace the dots in db name.
Like: 'demo.customerdb' to 'demo-customerdb'
You can use Sql Management Studio for db renaming:
connect target database server
select target database
press "F2" key or right click on target database then select
"Rename"
remove dots (.) from the database name and that's it! :)
After then, you can try migration process again from the start.
I just got approved for the Azure SQL Data Warehouse Preview, and just finished "provisioning" my new server and database. I followed a link to a 'Getting Started' page from Microsoft (Get started: Connect ...), and read that the two best (only?) ways of querying the database were through sqlcmd and Visual Studio 2013.
I ignored this advice first, and fired up SSMS, connected to the database, and then tried to open a new query window. I immediately received the following error: 'Unable to apply connection settings. The detailed error message is: 'NoCount' is not a recognized option.' After clicking OK, the query window did open up, but many T-SQL statements did not work such as a simple:
CREATE TABLE dbo.tblTest (acct_id nvarchar(255) NOT NULL)
I would receive a 'Command(s) completed successfully.' message, however no table was created.
Ok, I fired up Visual Studio 2013, connect to my Azure SQL Data Warehouse, and open it up in SQL Server Object Explorer. I right-clicked the specific database, and selected 'New Query', enter the same T-SQL CREATE TABLE statement as above, then hit execute. Once I hit execute, I get the exact same error message as above. This time around I was able to open a new query window at least, but after attempting to execute the query I still get the 'NoCount' is not a recognized option error.
I'm completely new to data warehouses, and still very much a beginner with T-SQL and SQL Server as well. But, I haven't been able to find anything that would explain why I'm receiving these errors, and right now I'm basically at a standstill until I can understand what's going on. Any help is appreciated, thanks.
I've experienced this. Your connection isn't actually recognised as a SQL DW connection. I bet your query window is a .sql file, not a .dsql as it needs to be.
Go back into the Azure portal and use the link to connect using SSDT from there. You should get a connection in the SQL Server Explorer pane which looks different, and when you start a New Query based on it, you should get a .dsql window, not a .sql one.
Have you checked the version of SSDT that you are using? It sounds like you may be on a version prior to 12.0.50623, which doesn't take into account that SET NO COUNT is not supported by SQL Data Warehouse at the moment. Newer versions of SSDT have adjusted for this. We recommend updating SSDT here and then connecting using the SQL Server Object Explorer with the directions in our documentation.
I am running Visual Studio 2015 Enterprise, and what I had to do to get this error resolved was install SSDT October 2015 Preview in Visual Studio. The link I used is: https://msdn.microsoft.com/en-us/library/mt204009.aspx
Prior to installing this, I had the latest released version for VS2015...had to install the Preview to get it to work. Also, it solved the issue where I was not able to see ANY of the tables in the Azure Data Warehouse database - just a couple of views, which made querying difficult (could still get a list of available tables from sys.tables)
I hope this helps somebody!
I'm trying to migrate a SQL Server 2008 R2 database to SQL Azure, I'm using the deploy database to azure wizard and am getting the following error:
Error SQL71564: The element Default: [dbo].[SystemDateDefault] is not
supported when used as part of a data package (.bacpac file)
I'm getting the same error code referencing a number default and a string default as well. I've never tried this migration before and have no clue where to even start with this.
Anyone had this before or have any ideas what I should be doing?
Thanks
Alex
I started by deleting Extended Properties (as my the error message stated, same SQL 71564 id). I used a script found here:
Drop all extended properties on SQL Server
But after many attempts I found it easier to script the entire db, make some adjustments, recreate the db from scripts and finally deploy to Azure.
I've had a bit of a dig around inside SQL and it turns out this is a default value for a user defined type.
I've removed it and things are going fine now.
Thanks anyway.
I'm running the copy database wizard on a 2008 R2 instance of SQL Server.
The database I want to copy is a SQL 2000 database.
I'm copy that database to another SQL SErver 2008 R2.
The wizard uses SQL authentication for both servers, and both are sysadmins.
When I run it, I get the following error (FYI I have tried both copying the logins and leaving them out):
Event Name: OnError
Message: ERROR : errorCode=-1073548784 description=Executing the query "sys.sp_addrolemember #rolename = N'RandomRoleName..." failed with the following error: "The role 'RandomRoleName' does not exist in the current database.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
helpFile= helpContext=0 idofInterfaceWithError={C81DFC5A-3B22-4DA3-BD3B-10BF861A7F9C}
StackTrace: at Microsoft.SqlServer.Management.Dts.DtsTransferProvider.ExecuteTransfer()
at Microsoft.SqlServer.Management.Smo.Transfer.TransferData()
at Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.TransferDatabasesUsingSMOTransfer()
Any help would be appreciated!
Jim
My suggestion is dont use the copy database wizard. Create a full backup of the database on the 2000 server and then restore it on the 2008 server.
If you google "Microsoft.SqlServer.Management.Dts.DtsTransferProvider.ExecuteTransfer Copy Database Wizard" you will find that many many people have gotten this same error or other nearly identical smo errors... no-one appears to have gotten past it.
That's isn't to say its impossible... just, restoring a backup is so much easier then the wizard or troubleshooting the wizard. Good luck.
The copy wizard had missed some security and IIRC it's caused by subtle differences in security tables, principals etc between the 2 versions.
Frankly, the easiest way is to do one of these two:
backup/restore
detach, copy, attach
If you don't have access to the O/S and can't get it, another option is to create the missing role(s) in the background as the copy runs. You have to catch it between the creation of the files and when it tries to reference the roles, but there are a few seconds in which to create them if you keep clicking execute - I managed to create 9 roles.
Unfortunately, you'll end up with the roles in another database too (while yours cannot be used) so those need to be deleted.
Of course, this is only an option when you really can't use the other method.
Though the answer which is using the backup technique solves the problem generally, after facing the same issue several times, I was able to trace down the root of the problem using the Event Viewer of Windows to that the Database Copy wizard, using the SQL Agent, will eventually create a Job for the agent to run, after which the Agent will run using its own credentials (i.e. the credentials that you can look up in Windows Services, in my case, NT Service\SQLAgent$SQL2014)
All you need to do is to go the folder where SQL Server creates DB files (e.g. C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\DATA by default for SQL 2014) and give the SQL Agent windows user write/read access on the folder.
The reason can be that a file with the new Database name already exist on the filesystem. We encountered this when we renamed Database X to X_Old, and tried to copy database Y to X. This cannot be done, because database X_Old is still associated with the filename X.
Either delete the conflicting database, or rename the file on the file system.
See http://codecopy.wordpress.com/2012/01/03/error-while-copying-a-database/
I am trying to edit or view the SQL Agent's job (I am the owner of this job) from SSMS 2005 and I can't find out how to do this. When I am double-clicking a job or entering job's properties I get empty "New Job" window.
Is there some way to correct this behavior?
You can genereate SQL Script for SQL Job and then edit it. right click the job and then
click generate SQL Script. Here you can also change the job properties with the sql sciript
I ran into this problem a while back. I'm not entirely sure what caused it, but the fix was installing sp2 of sql server onto my local machine (or whichever machine you're using ssms on). the only documentation i found at the time suggested that that was the only solution.
I suggest you create a new job explicitly, then try editing your new job the same way and see what happens.
In particular, it's possible that your old job really is empty.
not sure what your issue with SSMS is. Maybe you dont have permission?
Unless your sa you need to be a member of the SQLAgentOperatorRole in MSDB?
If you can still run queries then look at the sysjobs and sysjobsteps tables in the MSDB database, this has all the properties
You can use the sp_update_job to modify the job