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>


We are designing a system that will be written in C and accesses a relational database (using embedded SQL or possibly a popular RDBMS API). This a a very large application that will involve hundreds of modules and approximately 36 tables. The sheer size of the task complicates what can normally be considered a straight-forward method of passing parameters. We want to keep our database calls in a lower layer and have been kicking around alternatives for how to set up the calling interface.

We've come up with two different methods so far and corresponding issues:

  1. 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?
  2. 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.

So what have you folks done? Any slick ideas? Any experiences and suggestions would be greatly appreciated.

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.NA
Received on Thu Feb 11 1993 - 01:32:06 CET

Original text of this message