I have a small VB.Net 2005 application and MS SQL 2005 database.
It's a small ADO.Net application the thing is surprising me is that I did this project 100%
and it's working fine with me but after I send the project with the database to a friend. It did not work. I send the database as [DB_name].bak, my friend tried to restore it, it gave an error. he tried to create the database in his local machine, when he tried to connect it to the database it gave him a strange error:
(login failed for user 'win7-PC\Win7'), maybe this error occurred'
because there is no (win7-PC\Win7) user in SQL Security
You are getting the error because your app is using windows authentication to connect to the database. Simply add the user (win7-PC\win7) to SQL as a database owner for that database.
Related
I am trying to restored a .bak file on an Azure SQL server through SSMS.
The reason why I am doing this is that my company unfortunately blocked any action on the Azure portal itself and therefore I have to find another way around.
I am able to connect successfully to the DB on Azure with my admin account through SSMS.
I first successfully restored the .bak on my local database. And then I am trying:
Again, I am able to connect through the same SSMS to the SQL db.
Moreover, when starting this procedure I get asked to connect first to the DB, which works successfully! What I mean is:
It doesn't give me any error, which is weird because if I try to connect with a wrong password it tells me right away that is wrong. So it kind of accepts it. It's only after when I really start the deployment that it gives me the problem:
Just for now, Azure SQL database doesn't support restore from .bak file.
You work flow should be right, restore the .bak file(database) into a local SQL Server firstly, then deploy the restored database to Azure with "Deploy database to Microsoft Azure SQL database".
Make sure you are using the server admin account of the Azure SQL database. Per my experience, the error is usually caused by the permission limits.
If all of these(SSMS) don't work, please thy other ways. Please try Data Migration Assistant(DMA) migrate the database. If DMA still give the same error, we can ensure that it's not caused by the tools, you need another higher Azure SQL database account permission.
HTH.
Working solution was to use the export data task:
For some reason this worked and the publish to ASQL task from SSMS didn't. I understand this is very based on the restrictions imposed by my company but at least this solution worked.
NOTE: as both Source and Destination use SQL Server Native Client .
Moreover when setting the Destination the refresh of the list of databases might not work (depending on your permissions on Server level) but if you type directly the name of the database it will work. Talking about this:
So I am completely new to .Net Core development, and was given a codebase that I am trying to host on Microsoft Azure. I have the local database file (.mdf) in SQL Server Management Studio, and am trying to deploy it to an Azure Database, However it keeps failing during migration and giving me this issue
Error SQL71627: The element User: [ISOCENTRIC\Administrator] has property >AuthenticationType set to a value that is not supported in Microsoft Azure SQL >Database v12.
(Microsoft.SqlServer.Dac)
However, when I SELECT * FROM master.sys.database_principals; and it dumps the db users list, the "ISOCENTRIC\Administrator" user does not appear in that list, so I cannot find a way to drop it from the DB. Is there something I am missing regarding the location of this user and how I can drop it from the db so I can migrate to Azure?
p.s. This is my first post on here so please let me know if I should make any changes to adhere to correct formatting on this forum.
Thanks in advance.
I guess the database users can't be migrated to Azure SQL DB because they are Windows users. You'll need to drop those users before you deploy this database to Azure SQL DB.
You can always backup and restore a copy of this database, remove the users, and then deploy that one to Azure SQL Db.
I figured out that my query to dump the database users was incorrect, and was able to find and drop the user causing the issue.
We have a windows service that provisions Azure SQL databases for our clients. We are using Microsoft.WindowsAzure.Management.Sql API for this. Our service creates the SQL Server instance and deploys the schema using a DACPAC.
When running recently we received the following warning during the DACPAC deployment step:
Warning - Database 'AG61_xxxxx' on server 'xxxxxx.database.windows.net' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '{xxxxxxxx-C7D7-4504-AF25-4C3AC020BE90}'. (73144)
The problem we have is that this database is now left in an inconsistent state:
It isn't listed in the Azure Portal under databases.
The Azure API doesn't return it in list of databases on the server.
Attempting to recreate the same database on the same server, either via code OR via the Azure Portal, returns
Database 'AG61_xxxxx' already exists. Choose a different database name.
However, I can log into SSMS as the admin user and see the database listed. If I try to delete it I receive the following error:
Failed to connect to server. (Microsoft.SqlServer.Smo)
Additional information:
Database 'AG61_xxxxx' on server 'xxxxxxxxxx' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of 'FBE26206-C3B6-4771-B0EF-4BCA9C154F28'. (Microsoft SQL Server, Error: 40613)
According to Microsoft, error 40613 is transiant and should only last a few seconds. We've been unable to do anything with this database for 3 days.
Has anyone else experienced this? I'd like to know if there is something we can do to recover the database on this server such that we don't have to have the client change their connection strings etc.
I'd also like to know if there is anything I could do in future to mitigate this happening again.
As part of the effort for developing a Windows Service, I restored a production database to a test database on the same SQL Server instance, and can access the test database just fine via SSMS. I gave db_owner role to the database to two other users that are unable to login, both getting SQL error
Error: 18456, Severity: 14, State: 38.
Login valid but database unavailable (or login not permissioned)
Here is the basic message which mentions the database in question as the problem.
Login failed for user 'NT AUTHORITY\SYSTEM'. Reason: Failed to open the explicitly specified database 'MedFile_TestDataServer'. [CLIENT: ]
The database is not in "Restoring" status.
First user is NT Authority\System and the second a Windows user. Both credentials are used to run the Windows service that access the database in update mode, the system user from the same server, the Windows user from VS2013 running the service as a command program on my desktop. Both can get at other copies of this same database just by changing the database name so don't think a connection string issue. I have compared every property on the databases that work and do not work and see no differences except the file names and these two logins have less permissions on the databases that they can access.
Almost like this database is being kept unavailable after being restore but I can find no such property set on the database and I can access via SSMS. I've restarted the server containing the database ergo SQL Server as well.
I also tried running the service as a database administrator and get the same error even though that user accesses the db just fine via SSMS.
Is there anything that can make the database "unavailable"?
This is part of software development for a Windows service trying to use a test database. I am using both EF 6.02 and the latest ADO.NET version as well.
Check if your database has "Auto Close" property set to "True". If so, change it to "False".
You can see it from SSMS: right-click on database - Properties - Options.
can you check what is the Default database for those two users?
If you have (accidentally / purposefully) set a default database for the SQL Server Login user, and the user does not ahve permissions to access the database, you'll get this error.
We are troubleshooting a SQL Server 2005 connection issue on a closed-source third-party ASP.NET application. The application is a .NET application and the developing company is using a custom formatted configuration file that stores the SQL Server authentication information.
The application when trying to connect to our SQL Server box is getting a "Cannot open database 'databasename'. Login failed for user 'username'" error. We have tested connecting to the SQL Server box from the web server using SQL Server Management Studio and the login information provided to their app, it works perfectly.
Is there any easy way that we can sniff/determine the SQL Server Connection information they are trying to use inside their SqlCommand? Debugging their code is not an option, as it is compiled in Release Mode, and we don't have source. We simply need something to be able to identify why their app cannot connect.
run profiler and choose Security Audit: Audit Login, Audit Login Failed and Audit Logout events. choose all columns.
from that you'll get the app name, and the user that tries to log in from the login failed event.
once you get that check which database is default for that user in SQL Server users.
I just asked some of the guys here and they both recommended trying reflector. If you had some hard coded values in the library, you should be able to see something there.