Memory allocation using E-SQL

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Karl Stahl - 26 Oct 2004 23:09 GMT

I'm trying to dynamically allocate memory (on the heap) to store data I
retrieve from a Sybase database. Now I have code that uses stack memory and
looks like:

exec sql begin declare section
CS_INT data[1000];
etc.
select BLA BLA into :data

What I would like to do, ideally, is write something along the lines of:

exec sql begin declare section
CS_INT *data;
etc.
data = malloc(1000*sizeof(int));
select BLA BLA into :data

Alas, this doesn't work. Is it possible to dynamically allocate memory
using embedded SQL?

Thanks a-million,
-Karl

Reply to this Message

Ed prochak - 27 Oct 2004 17:38 GMT

> I'm trying to dynamically allocate memory (on the heap) to store data I
> retrieve from a Sybase database. Now I have code that uses stack memory and
[quoted text clipped - 18 lines]
> Thanks a-million,
> -Karl

Well, for every column in the SELECT you'd need a variable to accept
it's value, so what you are thinking won't work anyway. (at least not
in ORACLE Pro*C, and since you fail to mention any product, I'll show
my prejudice toward ORACLE)

You will have to do the work. Define a buffer big enough to accept the
longest value, fetch the next row, find the size of that value,
allocate the space just big enough for that value, and then copy the
data to that new memory.

Your example with an array of what looks like integers is puzzling.
Are you using a non-relational DB? One of those Multi-value systems
like PICK (no flame wars please)?

ed

Reply to this Message

Karl Stahl - 27 Oct 2004 18:12 GMT

Hi Ed,

Thanks for responding. I'm using a Sybase 12.5 database on a Unix platform.
Let me see if I can explain a bit better what my problem is (I think I
misled you by oversimplifying my example code). As my code is now (which
works), I declare a variable with a fixed size, e.g. CS_FLOAT data[MAX_NUM].
Then I create a cursor and fetch into this variable (or just 'select'
directly into the variable - I don't really know why I should use a cursor,
but that's what the guy before me did...). This all occurs within a C
function, so as soon as the function exits, the variable 'data' disappears.
If I want to access that data from another function, it must be in heap
memory, so I have to dynamically allocates space, e.g. double *data_out;
data_out = malloc(MAX_NUM*sizeof(double)); Then I copy the contents of
'data' into 'data_out' using: memcpy(data_out, data,
MAX_NUM*sizeof(double)). This is the step I would like to eliminate -- I'm
trying to streamline things as much as possible, and copying huge amounts of
data takes longer than I'd like (plus, it's just not elegant). Is it
possible to dynamically allocate space for variables in heap memory, then
'select' or 'fetch' directly into those variables (without memcpy)?

Thanks again,
-Karl

>> I'm trying to dynamically allocate memory (on the heap) to store data I
>> retrieve from a Sybase database. Now I have code that uses stack memory
[quoted text clipped - 35 lines]
>
> ed

Reply to this Message

Jarl Hermansson - 27 Oct 2004 21:11 GMT

> Hi Ed,
>
[quoted text clipped - 20 lines]
> Thanks again,
> -Karl

Karl,

First I want to make clear that I know nothing about Sybase. But I do
know some about the SQL standard's embedded SQL.

The answer to your question is No, there is no dynamic memory allocation
in esql. You'll have to keep copying data like you are already doing.

In embedded SQL, the scope of a host variable is one compilation unit.
(Which for C is one file.) This means you can move the variable
declaration to the top of the .ec file and then access the variable as
any other C variable. (Either move the whole declare section, or add a
new one.) So if your main program is in the same file as the routine,
this may perhaps help. (Or?)

About that cursor, if you are really sure your SELECT statement will
always return exactly one row, you don't need a cursor, just do a simple
singleton select:

exec sql SELECT col INTO :data FROM ...

Just remember that SELECT INTO can only be reliably used when there is no
possibility of a multi-row result set (essentially when the search
condition includes the columns that form a UNIQUE or PRIMARY KEY column
or returns just the result of a set function, e.g. COUNT(*)).

Otherwise you need that cursor.

HTH,
Jarl

>>> I'm trying to dynamically allocate memory (on the heap) to store
>>> data I retrieve from a Sybase database. Now I have code that uses
[quoted text clipped - 36 lines]
>>
>> ed

Reply to this Message