I'm running the following T-SQL statement from SSMS
CREATE DATABASE SomeDB
GO
With a result
Commands completed successfully.
But no database is actually created. I've been researching and came across this post which has the same behavior. The solution for that post was the run the script under an account with rights to modify sys.databases.
However, the user I'm running the script under and connecting to the DB as is in role sysadmin which is more than enough to create a database.
Any ideas as to what's going on here?
EDIT 1
If I change the script (and this is the whole script, with a DB actually called SomeDB to test), to the following
CREATE DATABASE SomeDB
GO
USE SomeDB
I get the following in SSMS's Messages panel.
Msg 911, Level 16, State 1, Line 56
Database 'SomeDB' does not exist. Make sure that the name is entered correctly.
If I change this to
CREATE DATABASE SomeDB
GO
SELECT * from sys.databases
I see the following in the Messages panel
Commands completed successfully.
But there is no Results panel. This would imply that access to sys.databases is restricted but it's weird that there's no error message.
EDIT 2
Taking this further and trying to narrow down the issue, I've run the following via an unelevated command line;
sqlcmd -S .\SQLExpress2014 -Q "CREATE DATABASE SomeDB"
And this time the database does exist. This narrows down the issue to SSMS itself rather than SQL Server or a syntax quirk.
Solution: Run SSMS as Admin.
Despite CREATE DATABASE working fine via an unelevated command line, SSMS requires admin privileges to do the same. The silent failure is...a possible bug?
I'll do further research on this but my working hypothesis is that when executing via a command line, it uses the SQL Server Windows Service instance's credentials (Network Service for older versions, NT Service\MSSQL$SQLEXPRESS for later versions - there's a strong whiff of a permissions issue here), to write to the %programfiles% folder. SSMS uses the currently logged in user (unelevated) if connecting via a Windows account. Without elevation, there is no write access to %programfiles%.
Still though, even if this is the case (to be verified), there should still be an access error when executing CREATE DATABASE in this context.
Right click on databases folder in Object explorer and refresh. Then check wheter DB exists or not..
1.- Run SSMS as Admin and create the database
2.- After the command shows it succesfully created the database, try disconnecting from the object explorer and connect again to see if it shows up.
Related
I have created an SSIS package that simply replicates 1 table to another (on 2 different servers). When I run the SSIS package from the designer, it works perfectly.
However, when I create an SQL Job as it needs to be run automatically. but it fails with a permissions issue.
I am logged onto the to the server with an administrator user.
I have googled this and have tried a host of different things, encrypting the password etc and trying to execute with a proxy user but nothing seems to work.
I would like to know what this user refers to here:
Its the domain name and server name, but I have no idea where this user exists or even if it is an legit user?
I want to install DB2 UDW in my machine for learning purpose but I am having a hard time configuring the local instance. Any help would be highly appreciated.
I installed DB2 express edition -c . I have selected all the default choices. I am trying to connect using IBM data Studio 4.1, In the "DB2 first Steps" GUI I have chosen to create SAMPLE Database. I am getting the below error
Creating database "SAMPLE" on path "C:"...
Existing "SAMPLE" database found...
The "-force" option was not specified...
Attempt to create the database "SAMPLE" failed
'db2sampl' processing complete.
I tried connecting from Data Studio using the following options
Database- SAMPLE
Port- 50000
host - localhost
Error I am getting
Explanation:
An attempt was made to access a database that was not found, has not been started, or does not support transactions.
User response:
Ensure that the specified database name exists in the system database directory. If the database name does not exist in the system database directory, either the database does not exist or the database name has not been cataloged. If needed, issue a db2start command and then resubmit the current command.
SQL4499N A fatal error occurred that resulted in a disconnect from the data source.
SQLSTATE: 08004
Problem is I am having zero knowledge in DB2. If I need to run db2start command from where I should run this? Please help
Probably the instance is not started.
Once you have installed DB2, you need to have an started instance in order to use any database. The instance could be created at the same time of the installation. You can verify which instances exist in your computer by issuing:
/opt/IBM/db2/V10.1/instance/db2ilist
The output should give you a set of users, where an instance has been configured.
You can change to that user and start the instance. For example if the user is db2inst1
su - db2inst1
db2start
Once the instance is started, you can now create a database and then connect to it.
I'm trying to set up a Stored Procedure as a SQL Server Agent Job and it's giving me the following error,
Cannot bulk load because the file "P:\file.csv" could not be opened. Operating system error code 3(failed to retrieve text for this error. Reason: 15105). [SQLSTATE 42000] (Error 4861)
Funny thing is the Stored Procedure works just fine when I execute it manually.
The drive P: is a shared drive on Windows SQL Server from LINUX via Samba Share and it was set up by executing the following command,
EXEC xp_cmdshell 'net use P: "\lnxusanfsd01\Data" Password /user:username /Persistent:Yes'
Any help on this would be highly appreciated
I do not know if you solved this issue, but I ran into the same issue. If the instance is local you must check the permission to access the file, but if you are accessing from your computer to a server (remote access) you have to specify the path in the server, so that means to include the file in a server directory, that solved my case.
example:
BULK INSERT Table
FROM 'C:\bulk\usuarios_prueba.csv' -- This is server path not local
WITH
(
FIELDTERMINATOR =',',
ROWTERMINATOR ='\n'
);
To keep this simple, I just changed the directory from which I was importing the data to a local folder on the server.
I had the file located on a shared folder, I just copied my files to "c:\TEMP\Reports" on my server (updated the query to BULK INSERT from the new folder). The Agent task completed successfully :)
Finally after a long time I'm able to BULK Insert automatically via agent job.
Best regards.
I have solved this issue,
login to server computer where SQL Server is installed get you csv
file on server computer and execute your query it will insert the
records.
If you will give datatype compatibility issue change the datatype for that column
Using SQL connection via Windows Authentication:
A "Kerberos double hop" is happening: one hop is your client application connecting to the SQL Server, a second hop is the SQL Server connecting to the remote "\\NETWORK_MACHINE\". Such a double hop falls under the restrictions of Constrained Delegation and you end up accessing the share as Anonymous Login and hence the Access Denied.
To resolve the issue you need to enable constrained delegation for the SQL Server service account. See here for a good post that explains it quite well
SQL Server using SQL Authentication
You need to create a credential for your SQL login and use that to access that particular network resource. See here
I would suggest the P: drive is not mapped for the account that sql server has started as.
It's probably a permissions issue but you need to make sure to try these steps to troubleshoot:
Put the file on a local drive and see if the job works (you don't necessarily need RDP access if you can map a drive letter on your local workstation to a directory on the database server)
Put the file on a remote directory that doesn't require username and password (allows Everyone to read) and use the UNC path (\server\directory\file.csv)
Configure the SQL job to run as your own username
Configure the SQL job to run as sa and add the net use and net use /delete commands before and after
Remember to undo any changes (especially running as sa). If nothing else works, you can try to change the bulk load into a scheduled task, running on the database server or another server that has bcp installed.
I did try giving access to the folders but that did not help.
My solution was to make the below highlighted options in red selected for the logged in user
For some weird reason I'm having problems executing a bulk insert.
BULK INSERT customer_stg
FROM 'C:\Users\Michael\workspace\pydb\data\andrew.out.txt'
WITH
(
FIRSTROW=0,
FIELDTERMINATOR='\t',
ROWTERMINATOR='\n'
)
I'm confident after reading this that I've setup my user role correctly, as it states...
Members of the bulkadmin fixed server role can run the BULK INSERT statement.
I have set the Login Properties for the Windows Authentication correctly (as seen below).. to grant server-wide permissions on bulkadmin
(source: iforce.co.nz)
And the command EXEC sp_helpsrvrolemember 'bulkadmin' tells me that the information above was successful, and the current user Michael-PC\Michael has bulkadmin permissions.
(source: iforce.co.nz)
But even though I've set everything up correctly as far as I know, I'm still getting the error. executing the bulk insert directly from SQL Server Management Studio.
Msg 4861, Level 16, State 1, Line 2
Cannot bulk load because the file "C:\Users\Michael\workspace\pydb\data\andrew.out.txt" could not be opened. Operating system error code 5(Access is denied.).
which doesn't make sense because apparently bulkadmins can run the statement, am I meant to reconfigure how the bulkadmin works? (I'm so lost). Any ideas on how to fix it?
This error appears when you are using SQL Server Authentication and SQL Server is not allowed to access the bulk load folder.
So giving SQL server access to the folder will solve the issue.
Here is how to:
Go to the folder right click ->properties->Security tab->Edit->Add(on the new window) ->Advanced -> Find Now. Under the users list in the search results, find something like SQLServerMSSQLUser$UserName$SQLExpress and click ok, to all the dialogs opened.
I don't think reinstalling SQL Server is going to fix this, it's just going to kill some time.
Confirm that your user account has read privileges to the folder in question.
Use a tool like Process Monitor to see what user is actually trying to access the file.
My guess is that it is not Michael-PC\Michael that is trying to access the file, but rather the SQL Server service account. If this is the case, then you have at least three options (but probably others):
a. Set the SQL Server service to run as you.
b. Grant the SQL Server service account explicit access to that folder.
c. Put the files somewhere more logical where SQL Server has access, or can be made to have access (e.g. C:\bulk\).
I suggest these things assuming that this is a contained, local workstation. There are definitely more serious security concerns around local filesystem access from SQL Server when we're talking about a production machine, of course this can still be largely mitigated by using c. above - and only giving the service account access to the folders you want it to be able to touch.
I had the same problem SSIS 2012 and the solution was to use Windows Authentication. I was using SQL authentication with the sa user.
Go to start run=>services.msc=>SQL SERVER(MSSQLSERVER) stop the service
Right click on SQL SERVER(MSSQLSERVER)=> properties=>LogOn Tab=>Local System Account=>OK
Restart the SQL server Management Studio.
Try giving the folder(s) containing the CSV and Format File read permissions for ‘MSSQLSERVER’ user (or whatever user the SQL Server service is set to Log On As in Windows Services)
This is what worked for me:
Log on SSIS with Windows authentication.
1. Open services and find MSSQL NT Service account name and copy it:
2. Open folder from which SQL server should read from. Security - Group or user names tab - Add and paste there copied account:**
You will probably get "Multiple names found error", just select MSSQL user:
Your BULK INSERT query should run fine now.
If problem persists try adding SQL Server Agent account to folder permissions in same way.
Make sure you restart MSSQL server in services after you are done.
This is quite simple the way I resolved this problem:
open SQL Server
right click on database (you want to be backup)
select properties
select permissions
select your database role (local or cloud)
in the you bottom you will see explicit permissions table
find " backup database " permission and click Grant permission .
your problem is resolved .
sometimes this can be a bogus error message, tried opening the file with the same account that it is running the process. I had the same issue in my environment and when I did open the file (with the same credentials running the process), it said that it must be associated with a known program, after I did that I was able to open it and run the process without any errors.
Make sure the file you're using ('C:\Users\Michael\workspace\pydb\data\andrew.out.txt') is on the SQL server machine and not the client machine running MSSMS.
1) Open SQL
2) In Task Manager, you can check which account is running the SQL - it is probably not Michael-PC\Michael as Jan wrote.
The account that runs SQL need access to the shared folder.
I have come to similar question when I execute the bulk insert in SSMS it's working but it failed and returned with "Operation system failure code 5" when converting the task into SQL Server Agent.
After browsing lots of solutions posted previously, this way solved my problem by granting the NT SERVER/SQLSERVERAGENT with the 'full control" access right to the source folder.
Hope it would bring some light to these people who are still struggling with the error message.
In our case it ended up being a Kerberos issue. I followed the steps in this article to resolve the issue: https://techcommunity.microsoft.com/t5/SQL-Server-Support/Bulk-Insert-and-Kerberos/ba-p/317304.
It came down to configuring delegation on the machine account of the SQL Server where the BULK INSERT statement is running. The machine account needs to be able to delegate via the "cifs" service to the file server where the files are located. If you are using constrained delegation make sure to specify "Use any authenication protocol".
If DFS is involved you can execute the following Powershell command to get the name of the file server:
Get-DfsnFolderTarget -Path "\\dfsnamespace\share"
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.