I've already googled both regular and groups, and it would appear nobody's
ever encountered what I'm encountering with one particular user of our
software.

It's written in VB 6.0 (SP6) running Btrieve 6.15 for Workstations (I know,
I know).

Those who are familiar with this older flavor of Btrieve might remember that
it used the three standard .DDF files (File, Field, and Index) and
additionally two optional files (Comment and IndexExt). The latter is the
one that is giving me fits. For whatever reason, an IndexExt.Lck file is
being created by an account OTHER than the user (even with nobody else in
the office at all, and after a fresh reboot) and the file becomes locked.
The user tries to access the data, and all "extended" type data, such as VB
Date and Currency are whacked - but only for the purposes of display. The
data is unchanged, but because the Smithware ActiveX Controls (later
purchased by Pervasive) apparently cannot access the FileExt.Ddf file and
instead of returning an error, shows all VB-Date fields as null date
(12/30/1899) and all currencies as if they were 8-byte integers (no assumed
decimal). This propagates throughout the entire accounting system until the
mysterious lock on FieldExt.Lck is manually closed or the server rebooted.

For now, at least we know there's no "real" data corruption at all, and we
know how to work around it, but it's maddening. Has anyone else ever
encountered anything like this? The server is Windows Server 2003 in case
that matters. Not sure of service pack(s).

Bill "Frisbee" Hileman

If your system has files called FILEEXT.DDF and INDEXEXT.DDF, then these
are not standard Pervasive files, and should not be related the the
standard FILE.DDF, FIELD.DDF, and INDEX.DDF.

FIELDEXT.DDF *is* a valid file for some systems that were built with the
Smithware DDF Builder, and it contains some extended field information
used by these old ActiveX Controls to handle some custom data types.
However, the FIELDEXT.DDF table has never been officially supported by
Pervasive.

An obvious workaround is to redesign the environment to avoid custom
data types, but this might be outside the scope of what you want to try.
I would recommend simply seeing which process is grabbing access to
the files, and ensuring that the engine on that machine is set to
MultiEngine File Sharing.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive Training - July 2009 in Chicago ***




Frisbee® wrote: