Question on array location

[rahzan]

I use CVF6.6b but I also would like to know hte answer for IVF.

If I deallocate a table and reallocate it again but with a different size, is there any way to ensure that it retains the same starting address in memory?

I know this is a wierd question but in case you want to know the reason:

Due to some quirk of ODBC API I am not able to write two different arrays (of different length) to the same table which has a primary key. It seems to work if I reuse the same array andSKIP the second SQLBindCol which is the routine used to announce the LOC of the array being written by SQLBlkOperations. This is a total kluge solution, but not having received any help from Canaima on this for weeks I am forced to go with it.

Could a Volatile declaration of the allocatable array do this?

bottom line: I need to be sure that the deallocate/reallocate will ALWAYS give the same LOC on the array.

[Jugoslav_Dujic]

Short answer: No.

Long answer: Not that I know of, and certainly not simple. Maybe you could play with low-level APIs such as VirtualAlloc, but even in that case you can't use native ALLOCATEs, only maybe Cray pointers (or cludge with array descriptors, which will turn out to be even uglier solution than your current one).

Jugoslav

[rahzan]

Thanks.

I thought so.

So we're back to waiting for Canaima.

If only there were a proper place to ask or read about the ODBC api!

Tim

[Jugoslav_Dujic]

microsoft.public.odbc.sdk

microsoft.public.data.odbc

If you don't have usenet access, there's still http://groops.google.com

Jugoslav

[rahzan]

The first isnon-existent. Have tried the secondand a host of others. Few if anyone, seems to know what I'm talking about when I mention odbc api. SO I rarely if ever, get a reply.

Have not tried google groups.

I am so tempted to write my own dbs based on ascii files.ms-SQL is sooooo horribly slow. It has nearly cost us our biggest client. ascii read/writes from cvf is at least 5 times faster than ms-SQL read/writes.

It is rediculous when a user-prgoram written on our platform (which uses cvf) takes 10 seconds to run, but it takes 30 seconds just to read the data and 90 seconds to write every time!

On top of that, one has to deal with this gobldy-**bleep** odbc crap which is like building a jigsaw puzzle trying do the simplest thing like write an array to a table!

Thanks.

TimH