I have two different C++ ISAPI DLLs that have been setup and configured for IIS 7 to use as web applications. They are setup using different application pools that are running under different domain user accounts. The problem that I am having is that, once one of the applications connects to SQL, the other application cannot. There are no differences in code between how the applications attempt to establish the connection – they both call the same static library method with identical parameters. The only way to get the second application to connect to SQL is to set its Application Pool user to the same domain user as the first application or vice versa (which rules out one user having insufficient permissions). I have double checked that ODBC connection pooling is turned on for the SQL Driver and I've monitored the ODBC Data Source Administrator Trace logs. If I monitor the trace log while both application pools are running under different users, SQLAllocHandle shows up successfully for both enter and exit in the Trace, but SQLDriverConnect will only succeed for both enter and exit for the first application that calls it. When the second application calls SQLDriverConnect with the exact same parameters, the trace only shows enter and debug logs also indicate that this function call never returns. Packet traces indicate that the second application never even attempts to connect to the SQL server. However, the first application will connect just fine and running a profiler in SQL will show proper execution of SQL statements. These applications ran just fine using the same multi-user configuration on Windows 2003 x86 under IIS 6 and older versions of the ODBC drivers.
I am hoping that there is a simple ODBC setting that I've missed, but my searches come up empty. Any help anyone can provide would be greatly appreciated, thanks in advance.
After over a week of troubleshooting and talking with Microsoft, we've finally found a solution. From what Microsoft told us, they changed the way that processes can interact with each other between 2003 and 2008 and using our static linked library like we were was causing a locking issue when it was running under different users. When we introduced a new thread before calling the ODBC connector, everything works fine.
Related
I have a fairly large Windows application (about 10 years old, written in c++) which works with SQL2000 Express (MSDE). It operates with database pretty extensively, but doesn't have performance issues. Due to SQL2000 MSDE compatibility issues with Windows 7/8 I want to migrate the application to SQL2014 Express.
All database access code is written in t/sql and as such the application migrates to SQL2014 without any code changes and all features work as expected. Except it's so badly slow it makes no sense to use the application under SQL2014. All select/update/insert queries take about 5-20 times more time to execute.
These are connection strings that I tried:
Provider=SQLOLEDB;Data Source=localhost\app;User ID=app_user;Password=password;
Provider=SQLOLEDB;Data Source=localhost\app;Trusted_Connection=yes;
I don't convert SQL2000 database to 2014 as the application creates a new database from scratch from scripts on its first run. Nothing fails, the default DB size is 12MB, the schema is pretty well optimised.
I also tried the same under SQL2008R2 Express - it's as slow as SQL2014 Express. Tried different PCs under Windows 7/8/8.1 - all the same.
The main detail which I noticed is that when I run the application under SQL2014 the most CPU consuming process in Windows Task Manager is "Local Security Authority Process". This process doesn't appear in Task Manager at all when I run it under SQL2000 MSDE and the application runs much faster. I guess LSA may be very heavy processing my "open connection" requests, but I don't know what to do about it.
The application is written is a way that it doesn't keep connections open, but creates them on demand and then releases. I tried to run SQL 2014 service under different accounts - it made no difference.
This process doesn't appear in Task Manager at all when I run it under SQL2000 MSDE and the application runs much faster. I guess LSA may be very heavy processing my "open connection" requests, but I don't know what to do about it.
Typically, lsass.exe (LSA) been used by IPSEC Services(PolicyAgent),
ProtectedStorage and Security Accounts Manager(SamSs)
Try to disable IPSEC Services(PolicyAgent)
We have a Plugin that runs on Browser. This Plug is a DLL that creates an out proc COM Server (say MyApp.exe). Note that this app runs as an elevated server as given here.
The Entry point for MyApp.exe registers the CLSID in to ROT. Hence when the Registration occurs to ROT I am not sure if it maintains any security context for the running process.
From the plugin dll we try to fetch the registered instance of MyApp.exe. This fails saying Operation is unavailable since the plugin is running through an browser as Medium IL Level. (Yes, it works for me if UAC is turned OFF, issue is only when it is turned ON).
I've tried the registry modifications as mentioned in the above link and it does not work for me.
Please suggest.
Thanks
I am getting an EOSError code 5 - Access Denied when the
TServiceApplication attempts to register the service with the
ServiceManager.
I am using XE2 Win7 64 bit. The error occurs for both 32 and 64 bit
targets.
I have a datamodule that uses ADO to connect to a database, and the web
services server code. All the code is used in a WinUI project which
works. I also have an untested ISAPI DLL based on the same core code.
This is the first time I have tried incorporating a Web Services Server
into an NT Service.
I have traced the VCL code that produces the error at line 1027 of
Vcl.SvcMgr but I don't know why I am getting the Access Denied error. I
have written other NT Services that connect to the database through ADO
and have not encountered such an error (although written with XE).
Any pointers would be appreciated.
You are likely encountering a UAC permissions issue that expects you to run the service install process in an elevated state, such as from a cmd.exe instance that was launched via the "Run as administrator" option, but you are not actually doing so. If you are having this problem with only some services and not others, then the affected services likely do not contain a UAC manifest but contain characteristics that are triggering UAC's Installer Detection feature, typically (but not restricted to) having reserved keywords in your service's filename or version resource.
I've got a C++ COM dll in Visual Studio 2005 that uses SQL Server (v2000) driver to connect to the database (SQL Server 2005). We've recently been tasked by our DB Team to upgrade our SQL Server driver from SQL Server (v2000) to SQL Native Client (v2005) or SQL Server Native Client 10.0 (v2007).
Application builds just fine. Then, when I go to perform the regsvr32 command on the DLL to register it for COM, the application hangs. When I debugged through the code I found that in the InitInstance of the main APP (which inherits from CWinApp) the application logs a startup message to the database using a stored procedure.
Debugging into that logging message reveals that a CDatabase object is created which executes the stored procedure. The stored procedure executes correctly; the message gets logged to the database and execution is returned to the C++ code. Then, when the CDatabase object is closed (by calling CDatabase::Close()) the application hangs. I debugged into the CDatabase code and found that in CDatabase::Close() a call is made to
AFX_SQL_SYNC(::SQLFreeConnect(m_hdbc));
It's in this call that the execution does not return. The debugger goes back to a (Running) state and nothing comes back. When I try and do a Debug -> Break All I get a message stating that there are no running threads and that the process may be deadlocked.
This only happens during the call to REGSVR32. And if I choose the Sql Server driver for the regsvr32 portion, then change it to the Sql Native Client or Sql Server Native Client v10.0 the application works just fine.
I'm working with Microsoft on this as well, but we're running out of time. Any help or thoughts would be greatly apprecaited!
Thanks,
The guy in the link below seem to have solved it by dynamically loading the ODBC dlls in his main APP and not only in the DLL. Could this be somehow applicable in your case?
SQLFreeHandle Deadlock Issue?
I'm pretty perplexed... I've got 5 different test computers, all relatively blank Windows XP machines running similar hardware specs. I run a silent install of the FireBird (Classic) database and my application. Some computers require "localhost:" (or 127.0.0.1) before the database location to make a connection, and some simply don't work at all! This is running the exact same software across the board. Does anybody have any suggestions as to what needs to happen to make the connection string universal, or what I could be doing wrong??
It's firebird version 2.1.1.17910 Classic
By the way, i tried connecting to the same database using FlameRobin (a small db management tool) and it worked just fine on the computers that don't connect.
Any more information necessary just let me know! Thanks a lot in advance
For anybody's future reference, the answer is in the services. Apparently it's not being registered as a service for some reason, and on the working computers, was at some point registered, probably through some sort of far earlier tests of Interbase is my best guess.
C:\Windows\System32\drivers\etc and opening up the file 'services' and adding the following line allows the server to run properly.
gds_db 3050/tcp
I'm not sure whether you are aware of that, but a connection string without "localhost:" or "127.0.0.1:" in front of the database name or alias will use the local protocol, which can't be used when connecting to Firebird Classic Server (see this link for more information). If a host name or IP address is given, then TCP port 3050 will be used for the connection.
If you have registered a server in FlameRobin, and did not leave the hostname field in the registration dialog blank, then the host name will be part of the connection string. That would explain why you can connect using FlameRobin.
As for the differences between the machines: You should first go to the Firebird Server Manager applet and make sure that the server is indeed running on all machines, and that the version is the same.
Does it have something to do with the hosts file on some of the computers? Or is that what you're referring to with your
Some computers require "localhost:" (or 127.0.0.1) before the database location...
comment?