Error $3C31 "Block number is either < 0, or >= number of block" (NexusDB V1.08)

oday I installed an app using NexusDB V1.08 for a new customer.
Server Win2000, clients mostly WinXP, TCP/IP transport. Developedwith
BCB6,
While testing, one user got the following excepting whileupdating a
record when calling Post ():
NexusDB: <unnamed TnxTable instance>: Block number is either < 0,or
>number of blocks in file [$3C31/15409]
The table had about some hundred records at that time. The error
occurred only once (a lot of other updates worked withoutproblems). The
table shows no other signs of corruption.
How to handle this error?

Best wishes from Bavaria
Karl

> NexusDB: <unnamed TnxTable instance>: Block number is either < 0, or
> >number of blocks in file [$3C31/15409]

We have seen this problem in the past but only when a table got corrupted
due to unexpected shutdowns of the server (power-offs or blue-screens)

Terry.

> The table shows no other signs of corruption.
> How to handle this error?

You should run Recover Records on it from Enterprise Manager. Any idea if
the server machine had a power outage or something while the test was
running?

--

Eivind Bakkestuen [NDD]
Please, no email unless requested.
Search Borland and third-party newsgroups here: www.tamaracka.com

Message by Eivind Bakkestuen [NDD]<Ieivind.bakkestuenHATE@nexusdb.comSPAM> on: 03.05.200516:20:03
>> The table shows no other signs of corruption.
>> How to handle this error?
>
>You should run Recover Records on it from Enterprise Manager.Any idea if
>the server machine had a power outage or something while thetest was
>running?

No, but I do not really know about the reliability of the servermachine
(it produced more than usual database errors with the old BDEsoftware
version, where it acted as data storage server only).
On repairing the table, three records went into the "_failed"table. Two
other days of testing passed without another error of this kind.
Thus, I have recommended the customer to get a new server machine(as it
is quite old anyway).
I have retained a copy of the table before repairing for the caseit is
needed for further analysis.

Karl

Yesterday, I installed the app at a second customer, on a newserver
machine (using WinXP) unpacked and installed just before. Thetables
were copied by my app record by record (thus not using anyspecial
import function).
After about a hour of testing, the same error occurred on thesame table
as at the first customer mentioned in the original posting citedbelow
(when trying to update an arbitrary record).
Then, I recovered the table using nxEnterpriseManager and renamedthe
table
tablename_Recovered.nx1 to tablename.nx1 (after copying
tablename_Recovered.nx1, tablename_failed.nx1, and the original
tablename.nx1, thus we can provide these files for analysis if
necessary).
Then we tried the same update, and the same error occurredagain.
Then, we reconfigured the app to rely on BDE again and installedthe BDE
on all the customer's new workstations (which was not ouroriginal
intent).
Now, we plan to try Firebird and IBObjects instead of NexusDB atleast
for that customer (our C++ app uses conditional compiling toselect the
database and its associated type names).

Somewhat disappointing.
How can our confidence in NexusDB be restored?

Best wishes from Bavaria
Karl
--
Message by Karl Pentzlin <kp0303@gmx.com> on: 02.05.200522:18:28
>Today I installed an app using NexusDB V1.08 for a newcustomer.
>Server Win2000, clients mostly WinXP, TCP/IP transport.Developed with
>BCB6,
>While testing, one user got the following excepting whileupdating a
>record when calling Post ():
>NexusDB: <unnamed TnxTable instance>: Block number is either <0, or
>>number of blocks in file [$3C31/15409]
>The table had about some hundred records at that time. Theerror
>occurred only once (a lot of other updates worked withoutproblems). The
>table shows no other signs of corruption.
> How to handle this error?

> After about a hour of testing, the same error occurred on the same table
> as at the first customer mentioned in the original posting cited below
> (when trying to update an arbitrary record).
> Then, I recovered the table using nxEnterpriseManager and renamed the
> table
> tablename_Recovered.nx1 to tablename.nx1 (after copying
> tablename_Recovered.nx1, tablename_failed.nx1, and the original
> tablename.nx1, thus we can provide these files for analysis if
> necessary).

Yes, please send it to me: hannes at nexusdb dot com.

> Then we tried the same update, and the same error occurred again.

Can you provide us the code for that update or describe what exactly it does?

> Somewhat disappointing.
> How can our confidence in NexusDB be restored?

I understand of course. Even though NexusDB 1.08 is running at thousands of
installation wihtout a problem there's obviously something wrong. Once we've
the tables and the details about the update we'll do our best to get to the
root of the problem.

--

Hannes Danzl [NexusDB Developer]
Newsgroup archive at http://www.tamaracka.com/search.htm

> After about a hour of testing, the same error occurred on the same
> table as at the first customer mentioned in the original posting
> cited below (when trying to update an arbitrary record).

Are you perhaps using encrypted tables?

--

Eivind Bakkestuen [NDD]
Please, no email unless requested.
Search Borland and third-party newsgroups here: www.tamaracka.com