Visual Studio DB Comparison Tool Falls Over with - SQL01270: Cannot open database - sql-server

I recently restored a database to my local dev machine from one of my colleagues.
I am logged in as admin. I have set the default database to the one I am trying to connect to. I have given the admin user db_owner permissions on Sql's User Mappings screen in SQL.
However when I run the sql comparison tool i get the following error:
SQL01270: Cannot open database "[ADMIN-PC.VirginActive]" requested by the login. The login failed.
Login failed for user 'admin-PC\admin'
The sql log files show the following:
2011-01-31 10:49:20.28 Logon Error: 18456, Severity: 14, State: 38.
2011-01-31 10:49:20.28 Logon Login failed for user 'admin-PC\admin'. Reason: Failed to open the explicitly specified database. [CLIENT: ]
I've looked around for "Error: 18456, Severity: 14, State: 38." on the googlemachine and the feedback I get is that the user cannot login to the box. However the user is the admin user, the same user who created the db.
Any ideas on how to get around this?

I just resolved the same sort of issue, but it wasn't the database -- it was the schema comparison file itself (the .SCMP).
Somehow my SCMP had gotten a fully-qualified [machine.domain\instance.database] representation of the database name in a few key places. I opened the file in Notepad++ and changed those to the simple name (just 'DW' in my case), and the problem was resolved immediately.
(The 'few key places' were: DatabaseName inside ConnectionBasedModelProvider, and the value of the TargetDatabaseName property.)

I had the same issue today. The fix that I found was that if you change the database owner of the database to another user (I used "sa", for instance) you will be able to successfully connect/make changes in the Visual Studio 2010 Database Schema Comparison.
To change the database owner, right-click on database name and go to files... your NT account is most likely listed there (mine was). Change that to "sa" or something appropriate and apply those changes and then try again. This worked for me.

This can still be an issue with file read/write-rights, try running all programs as administrator (if running vista/win7) and changing the security settings of the mdf-files.
Otherwise try to connect as a sql-user that you have created only for this purpose.

Related

Is it secure to deploy an SSAS Tabular Model package impersonating a specific user?

I created an Analysis Services Tabular Project in Visual Studio.
I tried to set the Impersonation Information to "Current User":
Unfortunately, I get the following error:
Failed to save modifications to the server. Error returned: 'The datasource, '[Datasource Name]', contains an ImpersonationMode that is not supported for processing operations.
If I instead set "Impersonation Information" to "Specific Windows user name and password" and use my personal account, it works just fine.
I got error messages for all other options (other than impersonating a specific account). For example, the "Unattended Account" option gave me the following error:
Failed to save modifications to the server. Error returned: 'An unexpected error occurred (file 'pcsspi.cpp', line 926, function 'GetImpersonationIdentity').
A connection could not be made to the data source with the Name of '[Data Source Name]'.
I do not handle the deployment myself - I move the entire solution to a shared folder and the tech lead for that particular project deploys it.
That being said, are there any security implications for impersonating my account? Any chance I could compromise my credentials?
Its totally fine to impersonate a specific Windows username and password however using your personal account is not correct. Set up a service account that has limited access to just the resources the Tabular model needs for refreshing. (Whatever data sources it uses and nothing else)

Where are credentials stored for SSIS data sources?

I'm setting up a development machine in which I need to maintain an SSIS package created by another developer. I can't get the package to run on this new machine, either in Visual Studio or as a SQL Server job. The most helpful message comes from Profiler:
Login failed for user 'MyUserName'. Reason: Password did not match that for the login provided. [CLIENT: <local machine>]
I know what the password should be, but I can't find where to set it.
To debug this, I've tried two ways of modifying the credentials to specify a different user, but the different user name is not being used in the connection attempts.
First I tried modifying the data source properties in Visual Studio.
Then I tried modifying the package config.
Data Source=.\SQL2014;User ID=DifferentUserName;Initial Catalog=dbname;...
The original user name is still being logged in Profiler, so I'm wondering where else to look for the credentials.

Login failed for user 'sa' while trying to create datasource with Railo

So I'm trying to setup Railo and I want to add a datasource.
For the database I'm using Microsoft SQL server Management Studio.
But now I've run into the classical problem: "Login failed for user 'sa'. ClientConnectionId:afd80ac2-0744-4a7d-a9f7-083d93adee0d"
What I've done so far:
With the SQL Server Configuration Manager in the TCP/IP settings I enabled the IPs I had to.
I set the password for the user 'sa' in MSSQL and I added a user mapping for the table I want to use.
I made the user 'sa' the owner of the DB i want to connect to
Restarted the SQL service, my computer and Railo multiple times.
I'm pretty much out of ideas.
After Leigh mentioned in the comments to look at my logs it had the following message: "Login failed for user 'max'. Reason: Failed to open the explicitly specified database 'test'. [CLIENT: 127.0.0.1]"
I then tried to make a connection without mentioning a database and that worked.
I would also point to Leigh's answer here which explains how to turn Mixed-Mode authentication on, as this can also cause this error. Since the cause of this isn't on Railo/Lucee's end, this issue still arises in 2018.
I just don't want a useful answer to get lost to history, nor plagiarize an answer I barely found.

What state is my SQL server database in when msdeploy fails on user creation?

I am using msdeploy (version 2) to transfer a database from machine A to machine B.
On in the database on machine A there are some users that do not exist on machine B, thus the transfer (partially) fails with the message:
Error Code: ERROR_SQL_EXECUTION_FAILURE
More Information: An error occurred during execution of the database script.
The error occurred between the following lines of the script: "3" and "5".
The verbose log might have more information about the error.
The command started with the following: "CREATE USER [someDomain\someUser] FOR LOGIN [someDomain"
Windows NT user or group 'someDomain\someUser' not found.
Check the name again. http://go.microsoft.com/fwlink/?LinkId=178587
The database seems to be transfered, except for the user creation. Does anyone know what state the database is in after this failure?
Is there any way I can transfer the database without the users (or better without specific users) using msdeploy?
Web Deploy uses SMO (SQL Management Objects) to script out and apply the scripts for SQL databases, and exposes most of the SMO settings with the dbfullsql provider (so, most of these options: http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.transfer_properties.aspx). If you want to skip the users due to this kind of login-not-exists or user-not-found error, you should be able to do this by adding the scripting option: copyAllUsers=false to the source of the sync. For example:
msdeploy.exe -verb:sync -source:dbfullsql="Data Source=.\SQLExpress;Initial Catalog=MySourceDb;User Id=localUser;Password=LocalPass",copyAllUsers=false -dest:dbfullsql="Data Source=RemoteSQLServer;Initial Catalog=MyDestDb;User Id=remoteUser;Password=RemotePass"
Incidentally, I am surprised you note the db appears to have been sync'd - I would expect this is not actually the case. If you have the permissions for it, Web Deploy will create the database if it did not already exist when it initially tries to make the connection, but your failure occurred very early in the script execution, and I believe Web Deploy dbfullsql syncs are transacted by default (the db creation is separate from the script execution and is not transacted). Thus the db may exist where it did not pre-sync, but I wouldn't expect the data to be present in it.

SQL 2005 Database diagram support objects cannot be installed because this database does not have a valid owner

I have two databases, production and stage. I am getting the error message in the title of this post when I click "Database Diagrams" for production, but on stage I don't get an error.
I've researched this message, and I've found posts such as this:
Link
They pretty much say to change the owner of my database to sa. I'm not convinced this is the issue, though, because both production and stage databases have the same owner (not sa), but I only get this error for production.
Does anyone else know how else to resolve this error message?
both production and stage databases
have the same owner (not sa), but I
only get this error for production.
That usually is the very source of the problem: a database created on one machine is restored on a different machine where the SID of the original creator is no longer valid. Change the owner to a valid one:
ALTER AUTHORIZATION ON DATABASE::[<dbname>] TO sa;
I received this error. In my case, I had existing Diagrams but could not view them on account of this error. I remembered that I had changed the name of the server a week or so ago. After renaming the computer, SQL Server (2012) apparently correctly began using the correct underlying local user object in the Logins section of Security. So, from appearances, the database had a valid owner. But the name of the security account wasn't changed - the username of the owner was correctly localputer\localuser but the SQL account name was local-puter\localuser (the original name of the server). I renamed the account name to localputer\localuser and everything went back to normal. I did not need to issue an ALTER AUTH ON DB.

Resources