After moving my database and web site for another server I got the error Microsoft SQL Native Client error '80040e37'.
The problem occurs in a query inside an asp file that do not have schema.tablename, only tablename. But I do not want to include "schema" in all queries right now.
All updates were installed and the default schema for my user is correct.
SQL Server is configure to mixed mode and to accept both windows authentication and sql server authentication.
Softwares: IIS 6, Sql Server 2005.
Solved. The problem was "Orphaned" logins. The solution was to run the stored procedure sp_help_revlogin, copy its results and run them in the new server.
EXEC [dbo].[sp_help_revlogin]
Example Result:
CREATE LOGIN [exampleLogin] WITH PASSWORD = 0x0100E634633EB1BF18E HASHED, SID = 0x840D462D26543B4FB71234B36137A131, DEFAULT_DATABASE = [yourDB], CHECK_POLICY = OFF, CHECK_EXPIRATION = OFF
Related
Using SQL Server 2019 Enterprise Edition (CU14)
I am attempting to use Polybase for reading data from a simple CSV text file.
When executing the create external data source I get the error "Msg 46721, Level 20, State 1 Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication."
The statement I'm using is:
create external data source datasourcename
with (
location = 'odbc:\\localhost',
connection_options='Driver=Microsoft Access Text Driver (*.txt, *.csv); Dbq=d:\data\; ApplicationIntent=ReadOnly;',
pushdown=off,
credential = <credential name> -- < On DEV server it works both with/without this
);
This actually works on my development server, however on the production server it is throwing this error and I can't find a solution. Not really sure what is trying to be logged in to!
On the Dev server (also SQL server 2019/CU14) I can even leave off the credential option and it still works.
Both servers are using the same domain account for the SQL Server service and Polybase services, I have defined the credential identically as:
create database scoped credential <credential name> with identity = 'Sql Server service domain account', secret = 'domain account password';
I don't think it's relevant but the production server is an Availability-Group secondary replica where I'm trying a simple proof-of-concept to test reading a CSV file and inserting data into TempDB.
On both my Dev server and Production server the file I'm trying to read is located in a folder on a local drive. The drive & folder has full control permissions for the SQL Server Service account.
Both servers have the same odbc driver installed, version 16.00.4999.1000
I have tried adding "trusted_connection=Yes and No" to the connection_options.
Connecting with SSMS I have tried using my own domain account and the SQL Server sa account.
I have installing the "Kerberos Configuration Manager" and connecting to the production server to check the SPNs and it reports "status good".
I have tried adding "DisableLoopbackCheck" registry key on the server.
So far nothing has worked and I'm at a loss as to what else to try.
The external data source definition is wrong: use forward slashes, don't use localhost, the odbc string is missing the curly braces, application intent is not a property of the odbc, and you don't need a credential. See this link for an example: https://36chambers.wordpress.com/2022/02/21/polybase-versus-flat-files/
Using Oracle SQL Developer I have migrated a very simple SQL Server 2012 database (with only 1 table) to Oracle 12c. Everything went as expected and the report looks as follows.
But when I try to connect the migrated database (Name - DummyDatabase) with username = DummyDatabase and Password = DummyDatabase, I am getting login failure issue as shown below. What might have went wrong?
Finally, I have figured out a fix. The login was failing because the user (i.e., DummyDatabase) itself is not created. This could be because of SQL Developer running generated script (i.e., master.sql) using container DB connection. And Oracle 12c won't allow any user to be created without "c##" prefix in container DB. Hence to fix this I have executed the following command to change the default behavior and then run the generated script in SQL Plus.
alter session set "_ORACLE_SCRIPT"=true;
How do I create a User using SQL code to join an SQL Server via SQL Server authentication mode. I used the code
CREATE LOGIN ANNACASSAR
WITH PASSWORD = '';
GO
CREATE USER ANNACASSAR FOR LOGIN ANNACASSAR;
GO
But I get this error:
Cannot connect to moscow\SQLSERVERMSWDEV.
Additional information:
login failed for user ANNACASSAR
(Microsoft SQL Server error 18456)
Set your server to Mixed authentication mode (right-click on the server in SSMS, Properties, Security, SQL Server and Windows Authentication mode, then restart the server).
However, you really should set a password, because it's a real security risk to create a login without a password.
I've created a linked server to an Excel spreedsheet. It's ok and working in SQL Server I can query excel file in query analyzer.
But when I'm trying to access this link server in my asp page:
Set pishbini = Server.CreateObject("ADODB.Recordset")
pishbini.ActiveConnection = MM_semmet_STRING
pishbini.Source = "SELECT * FROM OPENQUERY(SemnanmetWeekly, 'SELECT * FROM [DayPish$]')"
pishbini.CursorType = 0
pishbini.CursorLocation = 2
pishbini.LockType = 1
pishbini.Open()
SemnanmetWeekly is the name of linked server in SQL Server I'm getting this error in my asp page:
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]OLE DB provider
"Microsoft.Jet.OLEDB.4.0" for linked server "SemnanmetWeekly" returned
message "Cannot start your application. The workgroup information file
is missing or opened exclusively by another user.".
/Daypish.asp, line 15
IUSR (IIS user) has full access to excel file, I have played with all the different options in in my Link Server Options like impersonating or accessing excel file with administrator account, but error remained the same!
I prefer to not change the code, since I'm only doing administration stuff on this server. it has been working on an old server but since we moved it to new server it stopped working. anything I'm missing here?
Not related to permissions. I think you logged in to Sql Server with Windows Authentication, everything is okay, you're the boss. But, if the connection in ASP is SQL authenticated, you get this error. So, you should add a linked server login with a query similar to following.
Exec master..sp_addlinkedsrvlogin
#rmtsrvname = N'SemnanmetWeekly',
#useself = N'False',
#locallogin = N'sa', /* replace your own - same as sql server authenticated account */
#rmtuser = NULL,
#rmtpassword = NULL
Then you can connect to SemnanmetWeekly in your ASP application.
I am migrating a classic ASP web app to new servers. The database back end is migrating from SQL Server 2000 to SQL Server 2008, and the app is moving from Win2000 x86 to Win2003R2 x64. I am getting the above error on every single stored procedure call within the application.
I have verified:
Yes, the SQL user is set up, using correct username and password
Yes, the SQL user has execute permissions on the stored procedures in the database
Yes, I have updated the TypeLib references to the new UUID
Yes, I have logged into the database via SSMS with the SQL user id and it can see and execute the stored procedures just fine in SSMS, but not from the web app.
Yes, the SQL user has the database set as its default database.
The most frustrating thing is it works fine on the DEV server, but not on the production server. I have gone through every IIS setting 5 or 6 times and the web app is set up precisely the same in both environments. The only difference is the database server name in the connection string (DEV vs prod)
EDIT: I have also tried pointing the prod web box at the dev database server and get the same error so I'm fairly sure the issue isn't on the database side.
Are you sure that you are really connected to the instance and database you think you are (in the App)? It only takes the wrong DB in the connection string to override the default database for the user.
Can you execute some inline SQL on the connection like:
SELECT ##SERVERNAME AS SERVERNAME
,DB_NAME() AS [DB_NAME]
,CURRENT_USER AS [CURRENT_USER]
It might be the schema. Have you set the default schema of your user in the database you are using?