If a dbisam table has a default(?) no-name primary index on RecordID I will
get a index out of bounds opening the table using a tool like sql explorer.
Also an user using some Microsoft development tool is getting a error
"Attempted to read or write protected memory. This is often an indication
that other memory is corrupt."

Removing this index will solve this both for sql explorer and that Microsoft
dev. tool.

Kind regards,

Frans

Frans,

<< If a dbisam table has a default(?) no-name primary index on RecordID I
will get a index out of bounds opening the table using a tool like sql
explorer. Also an user using some Microsoft development tool is getting a
error "Attempted to read or write protected memory. This is often an
indication  that other memory is corrupt."

Removing this index will solve this both for sql explorer and that
Microsoft dev. tool. >>

I will make sure that this is corrected for the next DBISAM build.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>
> << If a dbisam table has a default(?) no-name primary index on RecordID I
> will get a index out of bounds opening the table using a tool like sql
> explorer. Also an user using some Microsoft development tool is getting a
> error "Attempted to read or write protected memory. This is often an
> indication  that other memory is corrupt."
>
> Removing this index will solve this both for sql explorer and that
> Microsoft dev. tool. >>
>
> I will make sure that this is corrected for the next DBISAM build.
>
What is the best work-around for now? Removing or ... ?

Frans,

<< What is the best work-around for now? Removing or ... ?  >>

There really isn't a workaround except removing the index.

--
Tim Young
Elevate Software
www.elevatesoft.com

Frans,

<< If a dbisam table has a default(?) no-name primary index on RecordID I
will get a index out of bounds opening the table using a tool like sql
explorer. Also an user using some Microsoft development tool is getting a
error "Attempted to read or write protected memory. This is often an
indication that other memory is corrupt." >>

I did some further looking into this, and I'm afraid that I can't really fix
this issue.  The problem is that the ODBC applications being used are not
respecting the fact that we're telling them that the RecordID field is a
psuedo-column when it is listed in the index columns catalog functions.  We
also can't just start listing the RecordID as a normal column in the table
columns catalog function, either.   That would completely mess up any
existing applications that populate rows by column positions, which is quite
a lot.

However, I will make a note in the manual about this situation.

--
Tim Young
Elevate Software
www.elevatesoft.com