Some limited solution is delay SQLDisconnect and SQLFree....
The problem easy to reproduce with ODBC test.
> > Greetings all,
> > This sound very like a bug I am chasing: hope no one minds
> > if I jump in.
> > I am currently completing a 16 bit application for a
> > client using MFC 1.52
> > and ODBC 2.X to access and MS Access database. The
> > database is accessed via
> > an AFX DLL. There are two clients, each with their own
> > database resources.
> > Problem 1:
> > After a hard reboot the following will cause a crash:
> > Client 1 starts and opens the database.
> > Client 2 starts and opens the database.
> > Client 1 exits and closes the database.
> > Client 2 exits and crashes when closing the database
> > (CDatabase::Close()).
> > If I remember correctly, it was in the call to
> > SQLDisconnect(). The error
> > is an illegal page fault in kernel32.dll.
> > What I guess is happening:
> > It appears some global resources are being allocated to
> > client 1. When
> > client 1 goes away, the resources are freed but
> > handle/pointer still exists
> > to resources. When client 2 tries to free the resources
> > (which are no
> > longer there) is causes the page fault and crashes.
> > The crash occurs in Win95 but not WinNT 4 (SP3)
> > It this is the same problem, it has been around for a
> > while.
> > Problem 2
> > To work around problem 1, I have the DLL creating a
> > database object and
> > opening the database before any clients have initialized
> > the AFX DLL so the
> > database is in the DLL memory space (and theoretically all
> > initial
> > resources are in DLL memory space.) All global resources
> > should initially
> > be created in DLL memory space. Since DLL is first to
> > allocate and last to
> > deallocate, the page fault should be avoided.
> > The crash of problem 1 is resolved and DLL seems to close
> > down OK.
> > However, after the 10th time we crash on database open.
> > The crash is in one
> > of the ODBC support drivers (most frequently VBAR2.DLL).
> > What I think is happening now:
> > There is some connection/resource which is not being freed
> > from DLL
> > database instance. After the tenth allocation, the driver
> > has maxed out and
> > crashes with GPF.
> > Anyone have other ideas?
> > ---
> > Information Integrity, Inc.
> > MS Windows Consulting
> > (508) 897-0801
> > > I'm currently creating an application that uses ODBC to
> > connect to
> > > datasources. The ODBC stuff (SQLConnect, SQLAllocStmt
> > ...) is implemented
> > > in C++ classes in a DLL.
> > > When my main application runs under Windows NT,
> > everything works OK.
> > > Under Windows 95 (With Service pack 1) everyting RUNS
> > ok, but when the
> > DLL
> > > unloads it creates a Access Violation in KERNEL32. The
> > SQLFreeStmt
> > > function seems to be the one creating this Access
> > Violation.
> > > I'm currently using VC++ 5.0 but the problem existed
> > under 4.1 and 4.2
> > > also.
> > > Any sugestions, anyone ????
> Blake and all.
> Check out bug #Q167731 on known MSVC bugs. In vesions from
> 4.2 on there is apparently some mismanagement of pointers in
> ODBC. They claim that the problem is fixed in the version
> 3.0 drivers, but I'm running into the same thing you mention
> above. Has to do with the SQLSetConnectOptions that is
> invoked during connection to DB.
> I have posted a bug up on their support line, but we'll
> Symantec Corporation