PRB: Making DB-Library Calls in a User-Defined DLL

• Microsoft SQL Server Programmer's Toolkit, version 4.2

SYMPTOMS

A user-defined dynamic-link library (DLL) contains all DB-Library (DB-Lib) calls and also a global dbprocess() function. The first call to a DLL function opens a dbprocess() function. All subsequent calls to the DLL attempt to use the same dbprocess() function to communicate with SQL Server.

When two processes run simultaneously, the first process to access the DLL opens the dbprocess() function and works correctly, while the second process fails when it calls a DLL function.

CAUSE

Two processes cannot simultaneously share the same dbprocess() function because the DB-Library's data segment is reserved.

WORKAROUND

There are at least three ways to achieve the same functionality:

• Let each calling process pass a dbprocess() structure into your user-defined DLL.
• Within your DLL, keep track of the processes accessing it and open a new dbprocess() function for each process.
• Open and close a dbprocess() function each time a DLL function is called (this obviously has run time trade-offs).

MORE INFORMATION

You cannot use a single dbprocess() function within a DLL for multiple .EXE files. DB-Library's data segment is reserved. This means that each process attached to PDBLIB.DLL (or W3DBLIB/WDBLIB) has its own private instance of a data segment. Therefore, one process never sees or accesses a dbprocess() function opened by a different process.

If you define the dbprocess() function globally in the DLL, it is stored in the shared data area and any process attached to that DLL can see it. However, PDBLIB.DLL (or W3DBLIB.DLL/WDBLIB.DLL) defines dbprocess() functions locally, so these are stored in the private per-process data area. Therefore, another process cannot see the dbprocess() data that is initialized by another process.

In OS/2 (that is, PDBLIB.DLL), only threads within the same process can access the same dbprocess() function opened by any one of them.