Robert,

<< Now the only mystery that remains is the #9480 error it generates. I hope
Tim can shed some light on this. >>

Are you using the latest 4.x version ?

<< But the problem is that even having one temporary table with a unique
name left would eventually (if you run the application often enough) result
in a #9480 error. How did you solve that? >>

The only way to solve that is to delete the .lck file when your application
starts up.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> << Now the only mystery that remains is the #9480 error it generates.
> I hope Tim can shed some light on this. >>
>
> Are you using the latest 4.x version ?

I am using version  4.22. Has this issue been solved in a later version?


> << But the problem is that even having one temporary table with a
> unique name left would eventually (if you run the application often
> enough) result in a #9480 error. How did you solve that? >>
>
> The only way to solve that is to delete the .lck file when your
> application starts up.

That's an option for my testsuite (where I have everything under my
control). But I can't do this at my customers sites. It would mean
stopping all client applications (they are running 24/7)


--
Robert.

Whatever you are, be a good one
===
http://robertcram.blogspot.com

Robert,

<< I am using version  4.22. Has this issue been solved in a later version?
>>

There was an issue prior to 4.25 with using CREATE INDEX in such a
situation - it would not open the table exclusively, thus causing an entry
in the lock file:

http://www.elevatesoft.com/scripts/incident.dll?action=viewrep&category=dbisam&release=4.25&type=f&incident=2297

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> There was an issue prior to 4.25 with using CREATE INDEX in such a
> situation - it would not open the table exclusively, thus causing an
> entry in the lock file:
>
> http://www.elevatesoft.com/scripts/incident.dll?action=viewrep&categor
> y=dbisam&release=4.25&type=f&incident=2297


Ok, that explains it - I'll try installing the newest version. Two
other issues I ran into are:

1. "select * from test as t exclusive" results in a parser error (just
omitting the "as" works fine - so it's no biggie)

2. creating a backup fails when the .lck is full

Maybe these are also resolved in later versions?


--
Robert.

Whatever you are, be a good one
===
http://robertcram.blogspot.com

Robert,

<< 1. "select * from test as t exclusive" results in a parser error (just
omitting the "as" works fine - so it's no biggie) >>

It's a bug.  The workaround is as you describe it.

<< 2. creating a backup fails when the .lck is full >>

It will - the lock file is full, therefore DBISAM cannot open the table for
shared access.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> << 2. creating a backup fails when the .lck is full >>
>
> It will - the lock file is full, therefore DBISAM cannot open the
> table for shared access.

I meant that a backup of the database fails when the .lck file is full.
Why would it have to add an entry to the .lck file?

If I incorrectly assume that a database backup should be working, how
"full" can the .lck file be before the backup starts failing?


--
Robert.

Whatever you are, be a good one
===
http://robertcram.blogspot.com

Robert

DBISAM needs to start a transation and all tables in the database were
locked to perform the safe copy of data. Think in RI and you understand why
they need to be locked.

Eduardo

Eduardo,

> DBISAM needs to start a transation and all tables in the database
> were locked to perform the safe copy of data. Think in RI and you
> understand why they need to be locked.

I understand why the tables have to be locked. What I don't understand
is why a NEW entry in the .lck table is needed (resulting in a database
full error).


--
Robert.

Whatever you are, be a good one
===
http://robertcram.blogspot.com

Robert,

<< I meant that a backup of the database fails when the .lck file is full.
Why would it have to add an entry to the .lck file? >>

If any of the tables that is being backed up is not already in the .lck
file, then it will have to add it.  Double-check your list of tables being
backed-up to ensure that it only includes the tables that you want to back
up and not any temporary tables, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> If any of the tables that is being backed up is not already in the
> .lck file, then it will have to add it.  Double-check your list of
> tables being backed-up to ensure that it only includes the tables
> that you want to back up and not any temporary tables, etc.

I didn't think of that - You're probably right. I'll test this and get
back to you.

In the meantime I have installed the latest DBISAM version 4.26b1.
Creating an index on a table when the lockfile is full still generates
the "database full" error. I can whip up a testapplication if you're
interested.

Another strange thing I've noticed is that when you use
TDBISAMTable.DeleteTable, it looks like the entry IS removed from the
lockfile (that shouldn't be happening, should it?).

--
Robert.

Whatever you are, be a good one
===
http://robertcram.blogspot.com