Looking for C & SQL parm tips/experiences.
From: Dave Egan - N6XVZ <daveegan_at_dhw68k.cts.com>
Date: Thu, 11 Feb 1993 00:32:06 GMT
Message-ID: <1993Feb11.003206.9136_at_dhw68k.cts.com>
Date: Thu, 11 Feb 1993 00:32:06 GMT
Message-ID: <1993Feb11.003206.9136_at_dhw68k.cts.com>
We've come up with two different methods so far and corresponding issues:
- Call the low-level SQL routine with a pointer to a structure that was obtained by the caller. Or should the called routine do the malloc()? We've seen cases where the caller had the storage defined smaller than the SQL routine, so when the low-level routine moved data into it, other storage areas following the row definition were corrupted (makes for a debugging nightmare!) Yet, if the called SQL routine gets the storage, how can you guarantee that the caller gets to or remembers to free it later?
- Code our SQL statements to return only the columns that are needed -- everyone says that is more efficient than returning a whole row. The issue here is that with hundreds of SQL functions, we'll have #include's for every one -- a maintenance nightmare. We could pass a single structure that represents the whole row and just "fill in" the columns we need, but when the row changes, all the affected programs need to be recompiled.
If there is sufficient interest, I'll post a response back to the net.
-- Dave Egan | Radio: N6XVZ uucp: ...{spsd,zardoz,felix}!dhw68k!daveegan | n6xvz.ampr.org[44.10.0.176] : daveegan_at_dhw68k.cts.com | n6xvz_at_wa6fwi.#SOCAL.CA.USA.NAReceived on Thu Feb 11 1993 - 01:32:06 CET