Fwd: Esql Query
Oops - I didn't mean to leave c.d.i in the dark on this. ---------- Forwarded message ---------- From: Jonathan Leffler <jleffler.iiug@gmail.com> Date: Mar 19, 2006 7:53 AM Subject: Re: Esql Query To: "vwbora@onetel.com" <vwbora@onetel.com> On 19 Mar 2006 04:15:52 -0800, vwbora@onetel.com <vwbora@onetel.com> wrote: > Your suggestion of using a vector is very good. As I am not entirely > comfortable with esql, I am not sure what can and can't be done and > hence whether I could use a Vector in this way. So just to clarify > ..... Remember, there's an element of hypothesizing going on - however, with a little caution, I think we are on safe ground. > Using a vector, > I could pass a reference of Vector<CustomerDetails> to the esql method. Yes. > Within the esql method, I could add entries to the Vector (via add). Qualified yes. Remember, the ESQL/C preprocessor does not understand C++; it barely understands C, come to that - just enough to be useful. What that means is that you'll need to make the variables that you collect the data from the database acceptable to ESQL/C. So, for example, you might be able to POD types in a struct - or POD types not in a struct - and collect the data in them. Then you collect these values and add them to the Vector - one operation or two. If one, then you simultaneously construct and add; if two, you construct and then add. > The add operation will reserve memory for entry. Yes. > Back in my C++ program, I can iterate through the Vector to read each > entry, > When the vector goes out scope, it should release any memory it had > reserved. Yes - precisely. > No need to dynamically allocate or free of memory. ? No manual allocation or release (unless you choose to do so). > Does the vector need to be have a size defined intially ? I don't think so. IIRC, there's a mechanism to reserve capacity - so you can tell it that you're going to need 10,000 entries and please don't allocate them all one by one - but that's something of an optimization. You'd have to check the definition of Vector in the STL documentation, the same as I would. > Much neater approach ... NP. The thing to remember when integrating ESQL/C and C++ is that ESQL/C is based on C compilers and C language - not on C++. The interface to your DB functions - those that separate the database access from the rest of the application - should be written in idiomatic C++. Internally, they will have to dumb things down to the point that ESQL/C can understand what it is supposed to do - in terms of the C types it understands. See also the esqlc++ package at the IIUG web site (which is probably overdue for an update; I've not validated it since GCC 4.0 was released, let alone 4.1; indeed, I suspect it was last checked on an early 3.x release). Nevertheless, it shows some of the ideas - not a POD to Vector mapping, but some of the ideas. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/ -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/