ORACLE INTERNALS

If you’ve ever played around with the Oracle Embedded SQL precompilers, you may have noticed a nifty little declaration for compilation unit data (CUD). While it’s named a bit differently depending on the host language, sqlcud0 (for Pro*C) or SQLCUD (for Pro*COBOL), its purpose remains the same. So, why am I spending time discussing the CUD? In addition to seeing several requests for further information in online forums, I’ve also received three or four inquiries from people wondering what in the world this CUD thingamajigger represents. After an hour or so of research, I may be able to describe it to you (a bit).Before we dive into the CUD, so to speak, let’s first discuss the architecture of precompilers and the code they generate. A SQL precompiler is a piece of software which compiles the SQL commands stored within a source program into appropriate database API function calls in the source language, such as C, C++, COBOL, FORTRAN, etc. After the precompiler has completed its work, a standard compiler is then used to build a binary executable or library containing the generated database function calls. In the Oracle world, we would look to using Pro*C for embedded SQL in C/C++, Pro*COBOL for COBOL, Pro*FORTRAN for FORTRAN, etc. However, as Oracle provides several client-side database APIs, it’s important to understand the one used by precompiler-generated calls, SQLLIB.

SQLLIB is a specialized library which, like OCI, is based on Oracle’s User Programmatic Interface (UPI). SQLLIB was designed to specifically deal wth the many aspects of handling SQL within a host language. You will find however, that SQLLIB is for the most part, undocumented. I believe there are two reasons for this. First, SQLLIB (like UPI), could change from release to release. As such, Oracle would have to update a lot more documentation, etc. The second reason, which is just my opinion, is that SQLLIB and UPI provide a proprietary interface into Oracle with more options than are presented in OCI.