Hi,

I need some help concerning status 81 with Btrieve 6.15 for Windows. My
application has been running OK in a Netware 5.1 environment for years.
Since a couple of days writing into the database causes status 81.

Startet my usual procedure:
Killing process w32mkde.exe didn't help.
Checking every WS to have no w32mkde.exe running and checking server no
files are in use didn't help.
Rebuilding database files with butil -save and -load didn't help.
Increasing 'Max Locks' didn't help (no surprise, was good enough for years)
Moving all database files to other server didn't help.
Moving all database filed to local drive, WORKS FINE.

Admistrator assumed, that updating the Netware client from 4.83 to 4.90
caused the error, because that's the only thing that has changed recently.

Any ideas?

Chris

You might check and make sure someone did not flag your Btrieve files as
shared. They should be flagged as not shared. Btrieve handles the sharing
issues.

"Ch. Marx" <NOSPAMcmarx (AT) computime (DOT) de> wrote

"Ch. Marx" <NOSPAMcmarx (AT) computime (DOT) de> wrote

I came across something today which might shed some light on your problem.
I was going through my 32-bit setup because of a problem I'm having with
6.15, and noticed an interesting setting.

Under Component: MKDE (Workstation Edition), Category: File Settings,
Settings: Delete Lock File, the accompanying text states:

Advanced: Tells whether to delete temporary lock files created during
multi-engine file sharing. Deleting may cause Status 81 on peer-to-peer
networks.

I have my setting to "On" but I'm not getting status 81. Then again I'm not
really developing in a sharing environment. I'm on a network, but I run
everything locally.

Just in -case- anyone can help me with my problem, which has had me stuck
for days now, my account app (VB 6.0 SP5) has a problem with one of the
files. It's an invoice posting thing where I've got ten files open using
the Smithware version 3.x ActiveX controls, one for each file.

Debugging is driving me nuts. One particular file, a G/L Session file, gets
updated with field information. Dumping the contents shows all fields
filled properly. Then I do an .Insert operation, and dumping contents again
shows correct info. However only about half the fields actually get
updated! Performing a get equal immediately after the insert and dumping
fields again shows several fields blank! I half suspect a corrupt DDF file,
as when I use Smithware's DDF Builder, it looks find in definition, but when
I attempt to look at the data directly, the indices combobox is quite
screwed-up. For example, it has three indices, like "Session Number" and
"Posting Period + Session Number". Those indices show properly in the
ActiveX control in the application, but in DDF Builder, they show as
"+Session Number" and "Session Number +"

I've been having sporadic problems with DDF Builder where I'll have to
occasionally rebuild file definitions, so I suspect I may have to again, but
does anyone know what causes this or have any similar symptoms?

BTW, attempting to update those missing fields via DDF Builder manually, the
fields go blank immediately upon clicking the "update" button, with no error
status.


--
Fris "frazzled" bee® MCNGP #13

http://www.mcngp.tk
The MCNGP Team - We're here to help

"Frisbee® MCNGP" <bhileman (AT) dasi-software (DOT) com> wrote

I now know why I was experiencing this bizarre behavior. Turns out that for
some reason the files were being created with the "variable length" file
flag being set! Oddly enough, over the years of developing this product,
I'd always been testing with converted data, never apparently creating new,
empty files. The process of creating new files is a different part of my
application than the part that creates new files for the purposes of
converting legacy data, and apparently there must be a flaw in my routine
that creates new files only.

My first clue was when I opened a rather old version of Smithware's DDF
Builder. It showed the names of my three indices in with the table
definition, as starting at offset zero for zero length. When I attempted to
edit data, it gave me a warning message that the "fixed length" of the file
was only defined as being 10 bytes! It is a fixed-length record file with a
record length of 50 bytes. No wonder it would lose everything except the
first ten bytes of each record! Strangely, however, doing a
..GetFileFlags(1) would return false interactively. Just the same, creating
new files with my conversion program instead of blank new ones seems to have
solved the problem, so there must be some flaw in the creation of new files
routine (which I will be digging into next).

Just wanted to post this in case anyone else ever observes the bizarre
behavior that I did. I still have a few hairs left on my head. Not many,
though.


--
Fris "Bald is Beautiful" bee® MCNGP #13

http://www.mcngp.tk
The MCNGP Team - We're here to help

I've got exactly the same problem here. Upgrade of Netware client from
4.83 to 4.90 seems definitely the cause. Downgrade of Client is a
workaround until someone comes with a fix...

"Ch. Marx" <NOSPAMcmarx (AT) computime (DOT) de> wrote

Check and see if Novell changed any defaults for the maximum number of file locks for a client. It
may just be a setting therein.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: September 16-18: See our web site for details!

René wrote: