Re: Fwd: Esql Query
Posted in 2006
Topics: SQL Development & Query Writing, Connectivity: ESQL/C, 4GL & Embedded SQL
Jonathan Leffler said: > Oops - I didn't mean to leave c.d.i in the dark on this. Well, I read it, but I'm still in the dark. :o) > ---------- Forwarded message ---------- > From: Jonathan Leffler <jleffler.iiug@gmail.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. -- Bye now, Obnoxio "It's easier with pictures." -- Cosmo "But wait, it gets worse." -- Cosmo "Run, don't walk, for the nearest exit." -- Cosmo
Obnoxio The Clown wrote: > Jonathan Leffler said: >> Oops - I didn't mean to leave c.d.i in the dark on this. > > Well, I read it, but I'm still in the dark. :o) It's easier to do that with some people than with others... -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
Related threads
- the longer you surf, the MORE $$$ you earn !!
- Store procedure
- emulation for Vt100
- extent size questions again ...