C++ and ESQL?

I am working on an HP9000 running HPUX 10.20 and we have an Informix Online engine running. Lately we have been doing quite a lot of MSWindows programming in C++ and hooking up with the Informix Database through Intersolv ODBC. We also write ESQL/C programs that run on the HP. I want to know how to write ESQL/C++ programs. Can anyone show me how to get started?

On Tue, 27 Jul 1999 14:54:57 -0700, ontop <ontop@worldnet.att.net> wrote: >I am working on an HP9000 running HPUX 10.20 and we have an Informix >Online engine running. Lately we have been doing quite a lot of >MSWindows programming in C++ and hooking up with the Informix Database >through Intersolv ODBC. We also write ESQL/C programs that run on the >HP. I want to know how to write ESQL/C++ programs. Can anyone show me >how to get started? I can give you an idea of how we did it. Its probably not the best method but it works. We wrote a bunch of C functions using Dynamic SQL to make ESQL/C calls. Then developed a C++ DB class library on top of this which is used by all our C++ application programs. Cheers, Vivek Venugopalan vivek(at)mcs(dot)net That was done to prevent spammers. Please remove the garbage in my <reply to> address before replying back to me.

Vivek, As I ponder my original question last night this idea came to me also. I am still new to Object Oriented Design and I am still thinking in terms of procedures and algorithms. It is a little for me to imagine how I encapsulate the Dynamic SQL calls and make the library, but I appreciate knowing that others have done this before. Thanks, John

In article <379E2AB1.EFFA238E@worldnet.att.net>, ontop@worldnet.att.net says... >Online engine running. Lately we have been doing quite a lot of >MSWindows programming in C++ and hooking up with the Informix Database >through Intersolv ODBC. We also write ESQL/C programs that run on the >HP. I want to know how to write ESQL/C++ programs. Can anyone show me >how to get started? If you really need to do ESQL in C++ source files, there are (or there were) some hacks documented on the www.iiug.org site that may help; the page you can look at them is http://www.iiug.org/software/software_index.html . If you can do it, the "wrapper" approach is certainly a good one and doesn't require that you mess around with special scripts or settings or anything. -- William Harris william@carsinfo.com Check out the NAGS spam filter. http://www.nags.org

ontop wrote: > Vivek, > > As I ponder my original question last night this idea came to me also. I am > still new to Object Oriented Design and I am still thinking in terms of > procedures and algorithms. It is a little for me to imagine how I > encapsulate the Dynamic SQL calls and make the library, but I appreciate > knowing that others have done this before. > > Thanks, > > John One of the problems I ran into attempting to encapsulate esql, is that the esql preprocessor injects static global variables into your code and generates hard-code cursor identifiers. This concept flys in the face of C++ which wants to encapsulate data within a class. In order to get around this in esql 5, my qery class had to redecale some of these static globals within the class. The scoping rules gave the class variables precedence over the esql globals. class Query { : : /** _SQNN: there should be as many of these as there are cursors inserted by esqlc preprocessing. These mask the static variables inserted into the source file by esqlc, allowing mutiple informix table objects to have simultaneous resources at the Informix Server. */ _SQCURSOR *_SQ1; _SQCURSOR *_SQ2; _SQCURSOR *_SQ3; /** _CnNN: there should be as many of these as there are cursors inserted by esqlc preprocessing. These mask the static variables inserted into the source file by esqlc, allowing mutiple informix table objects to have simultaneous resources at the Informix Server. */ RWCString _Cn1; RWCString _Cn2; RWCString _Cn3; }; There is additional logic to generate unique curor ids for _Cn1 through _Cn3 in the class' constructor. After that, the esql logic seemed to work quite well with in class member methods. void InformixQueryCursor::init() { _success = 0; _SQ1 = 0; _SQ2 = 0; _SQ3 = 0; // the following logic creates a unique version of a cursor id for this insatnce using the original // esql global id value as a seed. _Cn1 = ifxcursor_.InstanceOfCursor (::_Cn1); _Cn2 = ifxcursor_.InstanceOfCursor (::_Cn2); _Cn3 = ifxcursor_.InstanceOfCursor (::_Cn3); } Phil -- -------------------------------------------------------------------------- Philip Walden Hewlett Packard Supply Chain Information Systems 1501 Page Mill Road, M/S 5L-A Palo Alto, CA 94304 (415) 857-3899 FAX (415) 857-8234 http://www.scis.hp.com/~pwalden mailto:phil_walden@hp.com --------------------------------------------------------------------------

Philip Walden wrote: > ontop wrote: > As I ponder my original question last night this idea came > to me also. I am still new to Object Oriented Design and I > am still thinking in terms of procedures and algorithms. > It is a little for me to imagine how I encapsulate the > Dynamic SQL calls and make the library, but I appreciate > knowing that others have done this before. > > One of the problems I ran into attempting to encapsulate esql, is that > the esql preprocessor injects static global variables into your code > and generates hard-code cursor identifiers. Look again - not even in 5.00, though your complaint was valid for earlier versions of ESQL/C. From 5.00 onwards, you can use string variables to identify cursor names. There are essentially no globals introduced into your code. There are (probably) some function static variables for direct SQL statements that contain information like statement text and current variable binding information; you may still find these problematic. On the other hand, for dynamic SQL, there is no overhead like that. > This concept flys in the > face of C++ which wants to encapsulate data within a class. So, encapsulate cursor name and statement name in your class. It isn't C++, but DBD::Informix does this with statement handles quite happily. > In order to get around this in esql 5, my qery class had to redecale > some of these static globals within the class. The scoping rules gave > the class variables precedence over the esql globals. > [...snipped...] -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>