Btrieve 6.15.430 and error 80

[Roger Schaad]

Hi everybody,

We are running a VB application which performs quite a lot of batch
processing on several Btrieve files. The files are in 5.x format and
accessed using Btrieve 6.15.430 Microkernel. The files are on a NT server
shared drive.

After a few runs, we get status code 80 when trying to update a record. Once
this error appears, we can't update the record anymore, even after shutting
down the workstation. Status 80 is related to multi-user access, but we only
run one workstation.

Has anybody encountered a similar situation ?

Any help would be appreciated.

Roger SCHAAD

[Ginger Avenger]

We didn't Have the problem you mentioned but we found various miss reported
error codes when runing 6.15.430 Microkernel on 5.x files. (e.g Error code
14 appeared regularly but was actually a miss reported error 42) We found
that to stop the spurious errors we had to convert all the data files from
5.x format to 6.x format. This change cured many strange problems that we
were encountering. This may not help but hope it does.

--
----------------------------------------------------------------------------
--
life is never wasted, when your wasted all the time
----------------------------------------------------------------------------
--

[Tom Briese]

I'm not sure if this is an option, but if you are using the Workstation engine,
and are guaranteed of single user access, you could try setting Remote File
locking to Single User. I don't know if it will do any good.

Tom Briese

[Paul Rodden]

>We are running a VB application which performs quite a lot of batch
>processing on several Btrieve files. The files are in 5.x format and
>accessed using Btrieve 6.15.430 Microkernel. The files are on a NT server
>shared drive.
>
>After a few runs, we get status code 80 when trying to update a record.
Once
>this error appears, we can't update the record anymore, even after shutting
>down the workstation. Status 80 is related to multi-user access, but we
only
>run one workstation.

Yes, we recently encountered the same problem, but on a Novell server. We
were able to fix the problem by rebuilding the file. Same situation - Btr
6.15 on 5.x files. In our case, we lock the record just before updating a
given record. What I think happened to us was the lock is stored in the
record (or maybe page), and the update didn't release the lock like it was
supposed to. This (I think) caused subsequent updates to the same record to
fail with the 80 error. As I said earlier, rebuilding the file (using the
Butil -RECOVER and -LOAD) made it go away; methinks rebuilding the file
erased the lock information.

Hope this helps.

Paul Rodden
pro...@jwscorp.com

[Roger Schaad]

Thanks for the tip.

I didn't try to use Single Engine File Sharing but I will. Unfortunately,
SEFS does only allow a single application to access a file at a given time.
The application we are developping will access local data on a NT server,
but simulteanously with other applications, either on the server or on
workstations.

It may be true that SEFS resolves this particular issue, but we can't use
SEFS. Any other ideas are welcome.

Regards,

Roger SCHAAD

[Roger Schaad]

Hi,

Thanks for your answer. I am quite sure the status code is incorrect. I also
agree that we should migrate the data to the 6.x format. Unfortunately, we
still have legacy application running under Dos (using the Magic Tool 5.61)
which requires to stay in 5.x format.

We discovered that once you get the error, 8 records either above or beneath
the one which is in error, also give the same status when trying to update.
If we update one of this record using the Dos tool, then everything works
well for all 8 records. Unfortunately, the problem starts again when
accessing other records.

Any ideas ?

Thanks.

Roger SCHAAD

[Roger Schaad]

Hi,

I already tried to recover the file. The problem is effectively disapearing.
However, as our batch is running permanently, the problem appears again
later. The data file has can have around 500'000 records and therefore, we
can't afford to run a rebuild every time it appears. Furthermore, we could
imagine to do this if we had only one database, but the system is running in
about 500 different places.

Thanks anyway for your tip.

Roger SCHAAD

[Paul Rodden]

Ouch! Some additional information: We only have a couple of customers
running the 6.15 Client engine. We have about 1200 customers total, most
which are running either 5.x client, or the 6.15 NLM. The only time this
happened was on a 6.15 Client engine. The remainder who are running 5.x
Client or 6.15 NLM have not had this problem (over a span of a number of
years). From other experiences we've had with the 6.15 Client leads me to
believe it is a problematic product; I get the feeling running in DOS
protected mode just ain't what it should be. The 6.15 NLM has always
behaved well. I have no experience with the NT server version.

Paul Rodden
pro...@jwscorp.com

[Roger Schaad]

Hi Paul,

Thanks for your answers.

RogeR

Paul Rodden wrote in message ...