Microsoft KB Archive/65791

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;

  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.   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