INF: Using DBLOCKLIB & DBUNLOCKLIB in a Windows Db-Lib Program

ID Number: Q65791

1.10

OS/2

Summary:

The following are questions about the Windows example on page 98 in

the "Microsoft SQL Server Programmer's Reference" version 1.1

concerning the use of DBLOCKLIB() and DBUNLOCKLIB():

DBPROCESS *dbproc;

LOGINREC *login;

char far *name;

DBLOCKLIB();

login = dblogin();

DBSETLUSER(login, "user");

DBSETLPWD(login, "my_password");

DBSETLAPP(login, "my_program");

dbproc = dbopen(login, "my_server");

DBUNLOCKLIB();

1. Q. Why are the DB-LIBRARY (db-lib) segments locked in this example?

Is this really necessary? As I understand it, no far pointers

are returned from a db-lib function call.

A. DBLOCKLIB()/DBUNLOCKLIB() calls are required to preserve the

value of far pointers going INTO db-lib (dbbind) and OUT of

db-lib (such as dbdata).

Therefore, the example in the programmer's reference could be

executed without calling DBLOCKLIB()/DBUNLOCKLIB(). However, the

DBSET...() functions use strings, and for safety we recommend

that you use DBLOCKLIB()/DBUNLOCKLIB() calls to lock down

DB-LIBRARY.

2. Q. The dbsqlexec() function does not return a far pointer. Is it

possible to do a dbsqlexec() call in the following way?

DBLOCKLIB();

...some db-lib function calls

DBUNLOCKLIB();

dbsqlexec();

A. The same applies to dbsqlexec(). Because it does not return far

pointers, it is possible that dbsqlexec() would work without

locking the library down. However, to be sure that any far

pointers required by db-lib are preserved, it is safer to

encapsulate the db-lib calls with DBLOCKLIB()/DBUNLOCKLIB().

In summary, If you are certain that no far pointers are required by

the db-lib call and that no far pointers are returned, then, strictly

speaking, you do not need to use the DBLOCKLIB()/DBUNLOCKLIB() calls.

However, as a precaution, we recommend that you use these calls around

all your Windows db-lib calls.

Additional reference words: 1.10 dblib