I backed up my database table's and entire schema into .sql script using Visual Studio's Database Publishing Wizard.
I then tried to re-create those tables on another PC, not before re-creating the database itself, with the same exact name and everything (using a script that I created via SSMS's Script Database as).
I then open that tables .sql file using SSMS and execute it.
SSMS reports:
Command(s) completed successfully
But examining Object Explorer reveals that no tables were created.
Why is this happening?
What have I missed?
I've just been having the exact same problem symptoms also using Visual Studio's Database Publishing Wizard, - but with a slightly different cause / fix.
Even though SQL Server Management Studio says it is connected to the correct database (in the drop down in the ribbon, and in the status bar of the window), it wasn't actually connected to anything.
To identify and fix either:
SELECT DB_NAME() AS DataBaseName
If you get
master
(or any other unexpected database name) as the result, then you are connected to the wrong database and should select the correct DB from the dropdown. This was the cause of your problem.
If you get
Command(s) completed successfully
then somehow you aren't connected at all - this happened to me.
To fix, click the "change connection" button to disconnect and reconnect.
Check whether you have selected database. Most of the times we execute query in Master db by mistake.
-- Mark as answered if this answer really answered your question
Check if you are running "Execute" or jut Parsing the code. It was a late night, I was tired, and kept running a query to create a table, successfully, but no new table. The next day with a clear mind i noticed that i was not actually running the query, i was parsing it.
Related
I want to create a new schema in SSMS with the Schema - New dialog box but I can't find how.
I know it's supposed to open when I right click on the Databases/xyz/Security/Schemas folder in the Object Explorer and select New Schema... but all I get is a query to create it.
I just started an edX course called Developing SQL Databases, there are no instructions there concerning the SSMS settings, the only instructions say that I should be able to get the Schema - New dialog box. I asked there in the discussion but nobody replies, actually there's no activity there whatsoever so probably nobody even knows I asked.
I did google it but the only relevant results I found say the same thing, right-click, New Schema... and the dialog box opens. But it doesn't.
So, what am I missing?
Expand the database in the Object Explorer, and right-click the Security folder, then select "New" (the Security folder under the database, NOT the Security folder under the server).
I realize your question is how to do this in SSMS, but the tsql code for this is only five words.
create schema MyNewSchema authorization dbo;
That seems much simpler to me.
Be sure you are searching in a right folder.
the security folder is under the database , not under the server.
as next screenshot:-
UPDATE:-
This issue is repeated here, and the soluation was the following:-
Full uninstall Manual
deletion of all MSSQL-folders in
AppData{Local|Roaming}
Reinstall
Checking for any updates
and everything is as expected, so try these steps.
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 have a database in a local file that is used by a program. The program has limited functionality and I needed to run some quick queries. I installed SQL Server Management Studio Express 2005 (SSMSE), connected to the SQL Server instance, attached the database file, and ran the queries. Now the original program will no longer connect to the database. I receive the error:
Cannot open user default database. Login failed. Login failed for user 'MyComputer\MyUserName'.
I've gone back into SSMSE and tried to set the default database. I've opened up Security, Logins, BUILTIN\Administrators and BUILTIN\Users. Under General, I have set the default database to the program's database. Under User Mappings, I made sure the database is ticked and that db_datareader and db_datawriter are ticked.
The program uses the connection string:
Server=(local)\Instance; AttachDbFilename=C:\PathToDatabase\Database.mdf; Integrated Security=True; User Instance=True;
I know jack-all about database administration. What else am I missing?
This may not be answering your question specifically, but it may help others with similar issue caused by different problem
In my case the problem was my user is defaulted to a database which is not accessible for any reason (can be renamed, removed, corrupted or ...)
To solve the issue just follow the following instruction
Try to login again on the login page there is other tabs select
"Connection Properties".
under the tab locate "Connect to database" and select an existing database you have access to like tempdb or master
Once you are connected to the SQL Server Instance execute the below TSQL to assign the login a new default database.
Use master
GO
ALTER LOGIN [yourloginname] WITH DEFAULT_DATABASE = TempDB
GO
Alternatively once you connected change your default database name to master via UI
Article taken from :
http://www.mytechmantra.com/LearnSQLServer/Fix-cannot-open-user-default-database-Login-failed-Login-failed-for-user-SQL-Server-Error/
This problem manifested for me when I took my default db offline. Next thing I know I couldn't login. Switching to the Connection Properties tab and selecting the drop down to change the database I want to connect to also failed.
It let me in right away once I manually typed master as the db I wanted to connect to (on the Connection Properties tab).
First, try to isolate your problem:
Take a backup of the file! Some of the steps below can, apparently, in some circumstances cause the file to vanish.
Are you sure you are connecting to the same instance through Management Studio as the program is?
If possible, try to shut down the instance that you are not expecting to use.
Set the user's default database to master and try to make the program logon.
Try to login as the user through Management Studio - since you have integrated security, you should open Management Studio as the program's user.
Are you using "User instances" - perhaps without knowing it? If so, this may be helpful: http://blogs.msdn.com/b/sqlexpress/archive/2006/11/22/connecting-to-sql-express-user-instances-in-management-studio.aspx
I haven't worked much with files being attached in the way your program does - but you write that you attached the DB in the Management Studio as well. Have you tried detaching it there before running your program? Perhaps you are seeing the Management Studio and your program competing for exclusive access to the MDF-file?
EDIT: I added point 6 above - this is new in my own list of TODOs when troubleshooting this type of Login failed. But it does sound a lot like what you're experiencing.
EDIT2: In the first edit, new item was added to the list. So the numbers in the comments doesn't correspond with the numbers in the answer.
I finally figured this out, and my situation is different than every other I've read about tonight.
I had restored my database from a backup. I knew that there was a particular login user that I had been using, so I created that user in SSMS. However, there was already a user by that name under the database that had come in with the backup.
Since I had screwed around so much trying to fix this, I wasn't able to delete the user under the DB easily. I deleted the database and restored again. Then:
Delete the user under the Databases->[my database]->Users
Create the user again in Security->Logins (not under your DB, although that probably works too.
Go to the newly created user. Select properties. Then under User Mappings, tell it to make your database the default. Give it read and write access.
Summary: I had two users. One that came with the DB, and one that I had created. Remove the one that came with the DB and create your own.
First click on Option>> Button of “Connect to Server” Prompt.
Now change the connect to database to any existing database on your server like master or msdb.
More Details
https://blog.sqlauthority.com/2008/11/04/sql-server-fix-error-4064-cannot-open-user-default-database-login-failed-login-failed-for-user/
I've also had this same problem, it turned out that I was trying to access the built in membership classes (in a view), and that .Net was trying to create the database in the App_Data folder:
#Membership.GetUser().ProviderUserKey
This will trigger the system to try and create a database based in the built in membership system, which may not be the way your system is setup.
I had a similar problem had to simply download SQL Express Utility that is capable of starting User Instances. SSEUtil is a tool written by the Visual Studio team to help troubleshoot User Instance issues, you can read more about it in the read me file that is installed with the utility.
http://www.microsoft.com/downloads/details.aspx?FamilyID=fa87e828-173f-472e-a85c-27ed01cf6b02&DisplayLang=en.
Hope this will help.
In my case I had to set "connect to any database" right path:
On your instance, go to Security , then to Logins.
Right Click on there, you will see properties and you should click on Securables.
There it give possibility to connect to any database.
I HAVE to be missing something really simple here!
I have a database in my development environment called Project.
I have a database in my test environment called Project_UAT.
I've created an SSIS package that successfully copied my database from Project to Project_UAT. I'm pretty sure this eliminates most permission and configuration issues.
Now, I want to re-create the package and this time allow it to overwrite the destination, which is Project_UAT. This is simply because from time to time I want to click a button in the Microsoft SQL Management Studio that pushes the new database schema, data, users, and everything, out to my testing environment. I WANT to overwrite the data.
So I create the package just like I did before, but this time I specify the already-existing database name as the "Destination database" and I select the radio button called "Drop any database on the destination server with the same name, then continue with the database transfer, overwriting existing database files."
I click Next, and what does it tell me?
"Database name already exists at destination"
Well, I KNOW! I just told you I want to overwrite it!
How do I make this work?
Not sure if I am missing the point but why do you not use a task to drop/delete the existing database prior to your deployment step?
Perhaps you could qualify the SSIS Component Tasks you are using within your SSIS package.
Cheers, John
You can add an Execute SQL Task into the Control Flow to drop the database. Just set the SQLStatement property to
DROP DATABASE Project_UAT
After this step is executed the new copy of the Project_UAT database won't have to overwrite the old one.
I had this problem because I deleted the database before hand. The database is not in the destination folder, but SQL Server 2008 still thinks it is there. Refresh didn't work. And SQL Server wouldn't honor the selection of "Drop any database on the destination server..." It just complained that the database already existed.
Guys this is a common sense solution. A lot of complexity for nothing.
Backup the destination database you want to copy to and delete the destination database.
Open the copy database wizard and follow the steps.
Use the detach and attach method.
When you get to the configure destination database use the option if destination database exists select drop database on destination server with same name.
Now it will continue to the next screen.
But this only works if you delete the destination database first before starting the wizard.
I may have missed something but this worked for me.
Hey All, I have been working on this problem for a while and the usual google searches are not helping :(
I have a production database in SQL 2000. I want to copy it over the top of a training database to refresh it. I want this to be something that is scheduled to happen once a week to keep the training database up-to-date.
I have a DTS job created for doing this. Within that DTS job I have a single "Copy SQL Server Objects" task. That task is set up to:
Create all copied objects
Drop destination objects first
Copy data
Replace existing data
Copy indexes, triggers, primary and foreign keys
Copy all user tables, views, functions and stored procedures.
When I run this DTS package (in pre-production for testing of course) it gets to 99% done and throws the following error:
Step Error Source: Microsoft SQL-DMO (ODBC SQLState: 42S02)
Step Error Description:[Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name 'dbo.vwEstAssetStationAddress'.
Step Error code: 800400D0
Step Error Help File:SQLDMO80.hlp
Step Error Help Context ID:1131
My searches on the net didn't provide much help. There are reports of these errors getting hit, but none seem to match my circumstances. One suggestion I found was the the sysdepends table had become corrupted, making the DTS job run its scripts in the wrong order. Howeever, I ran the following script to correct that table and it still throws the same error:
USE master
GO
ALTER DATABASE [DATABASE NAME]
SET SINGLE_USER
GO
USE [DATABASE NAME]
GO
DBCC CHECKTABLE('sysdepends',REPAIR_REBUILD )
GO
USE master
GO
ALTER DATABASE [DATABASE NAME]
SET MULTI_USER
GO
I have also seen that having different object owners can cause this error. But I have confirmed that the objects are all owned by the dbo user in this case.
Any suggestions?
I feel stupid, but am posting the answer I just found for posterity (and so all you helpful fellows can stop stressing on my behalf.
Even though I had selected all the user tables, views, stored procedures and user defined functions to copy, I hadn't selected "Include all dependant objects". I had assumed that if you selected two objects to copy, and one was dependant on the other, SQL would always do them in the correct order. Aparrently not. Selecting this little check box made all the difference.
Thanks again to those who helped with suggestions
Somehow the dbo.vwEstAssetStationAddress table is not being found by your DTS package. Unfortunately, the message doesn't say if it was on the source or destination that it couldn't find it.
What are the exact steps, in the order that you have them in your DTS package? I'm assuming that the list of the task items above is not in order. I know this not an answer, but it looks like we are going to need a bit more information to help you further.
Thanks for the response hectorsosajr.
the object aparrently causing the error (dbo.vwEstAssetStationAddress) is a view that references 2 underlying tables. I have tested querying the view, as well as running the SELECT statement that defines it, on both the source and destination databases and it works fine.
The database object copy task in DTS doesn't allow you to specify the order it transfers things in. As far as I understand it, it uses the sysdepends table to determine the requisite order of events.
I was trying to avoid doing it via backup / restore. There are some users of the database that are SQL Server accounts (not Active Directory). This becomes a pain in the but if you need to do it from one server to another as you have to drop those users and recreate them.
Sounds like it is trying to create a stored procedure/view based on a view that doesn't yet exist.
Why not just backup and restore the database under a different name? (if it wasn't production, I would say detach, copy and re-attach). You can do all that under the control of T-SQL.
See if this link helps you find your dependency issue.
I've run another test to try and isolate this. I removed the mentioned view from the destination database totally, then ran the DTS again. It failed with the same error. However, the view that aparrently is an invalid object name was recreated successfully. It seems that the error is coming from something trying to reference that view, but it doesn't actually stop the script when it hits that error.
Cade - I will check out that link. I will also try and establish what is referencing the view and breaking.