Re: Pro*C host arrays: how big?

In article <CK6IwH.E4_at_uk.ac.brookes> Tommy Wareing, p0070621_at_oxford-brookes.ac.uk writes:
>I'm trying to work out how to tell it that the array elements are the
>bigger than they really are, so that I can interleave them and make
>Oracle see my array of structures as a set of arrays.

I expect that this could only work if all elements are read into host variables as strings (or similar things, such as HEX ?). It won't work for numeric host variables (float, int). You also have to ensure that Pro*C doesn't fill the entire space you give it (e.g. with blank padding or extra-long values). I seem to remember that they added the option to tell Pro*C how to treat the memory you've given it (e.g. to use null-terminated strings). You almost certainly can do it with Method 4.

There is a nasty hack for making Pro*C think one thing and C think another (I presume it still works, though I haven't coded anything in a couple years).

#ifdef SEEN_BY_PROC_ONLY

EXEC SQL BEGIN DECLARE SECTION;   declarations for Pro*C

EXEC SQL END DECLARE SECTION; #else

  ... real declarations of same names, potentially including macros   

#endif

You never even needed to do the #define (or -D on UNIX compiler), since Pro*C 1.x
looks at things in the DECLARE SECTION (and ONLY those things), ignoring the #ifdef. I don't suspect you would need this for your purpose (if it could work at all).

Of course, all of this weird, unsupported kind of stuff is somewhat prone to failure in future versions of the precompilers/database.

>
>> In general, I think Simon
>> The copying within your program usually isn
>> prefer to use structures).
>
>Beg pardon?

I hate it when that happens. What I tried to say is:

In general, I think Simon's suggestion of roughly 100 is pretty reasonable. That tends
to be a good compromise with overhead and memory (unless you are working over expensive networks, in which case you may want more). The copying within your program usually isn't very expensive compared to the rest of the stuff that goes on. And of course can be avoided if you're willing to deal with arrays of scalars (yeah, I know, yuk). Received on Wed Jan 26 1994 - 00:47:34 CET