Very Computer

Hi All,

I am encountering a problem where we are getting status 2's on our
database files. Now, it turns out that when we do a STAT on the file
everything seems fine( i.e. the file is not corrupt in anyway), also if
we copy the original file and then delete the original file and rename
the copied file to the original name the file is no longer giving a
status 2.

We have downloaded the the turbo-diss NLM and this still does not
resolve the problem.

Does any one have any ideas ???

Thanks

AntX

Sent via Deja.com http://www.deja.com/
Before you buy.

One of our vendors has suggested having a page size of at least 4096.

Tom Kustner
Emjay Corp. - A Wells Fargo Company

Any opinions are strictly my own and not necessarily those of Wells Fargo.

Note that STAT doesn't check the entire file. You'll have to STEP NEXT and FIND
NEXT (for all indexes!) through the whole file to make sure all data and index
pages are still intact.

Patrick

Quote:

>Hi All,

>I am encountering a problem where we are getting status 2's on our
>database files. Now, it turns out that when we do a STAT on the file
>everything seems fine( i.e. the file is not corrupt in anyway), also if
>we copy the original file and then delete the original file and rename
>the copied file to the original name the file is no longer giving a
>status 2.

>We have downloaded the the turbo-diss NLM and this still does not
>resolve the problem.

>Does any one have any ideas ???

>Thanks

>AntX

>Sent via Deja.com http://www.deja.com/
>Before you buy.

Quote:> One of our vendors has suggested having a page size of at least 4096.

Thought I'd jump in on this one - since it has been a BIG headache for
me more than once.  With a page size other than 4096, and a LARGE
Btrieve file, you can get status 19.

I have also experienced getting a Status 2 that goes away by stopping
and starting the Btrieve server -- which is not always an easy task.

Jeri

 Sent via Deja.com http://www.deja.com/
 Before you buy.

Our company has seen this problem as well.  We have had copies of
status-2-yielding files downloaded to us and there would be no instance
of an error with the file here.  I wrote a program to traverse all the
indexes (forwards and backwards) and no status 2 would result.
Afterwards, I had the system administrator rename the status 2 file,
and copy the status 2 file back to the original name, and the status
2's would cease.

I have only ever had this problem with Novell servers, running the
Btrieve.NLM, even if the supposed turbo-fat-cache fix is installed.
There is obviously still some sort of related bug in Novell (even
Novell 5!) and Novell seems to have no interest in figuring it out.
For now it seems the only solution is the rename-and-copy technique. I
have seen where stopping and starting the NLM does not fix the problem,
however rebooting the entire server does.  This again points to a
server-level caching problem (internal to Novell).

If anyone hears something more definitive from Novell on this issue I
think we all would like to hear it.

== Ron DeFulio

Sent via Deja.com http://www.deja.com/
Before you buy.

What is the easiest way to modify the page size?  I have BSETUP configured for
4096, and the /D: parameter of BRequest.exe setup for 4096, but it still seems to
create files with a 2K page size.

Any advice will be appreciated!

Thanks

David Blum

--
David P. Blum
Krane Products, Inc.
4800 North Federal Hwy
Suite 300E
Boca Raton, FL 33431
tel 561-362-5902
fax 561-362-8893

See my posting above.  Our vendor told us that Pervasive might have
finally resolved the problem in P.SQL 2000, SP1.

Tom Kustner
Emjay Corp. - A Wells Fargo Company

Any opinions are strictly my own and not necessarily those of Wells Fargo.

I talked to the vendor after my first posting.  We are planning to
upgrade to P.SQL 2000.  The vendor said that after applying SP1 to
P.SQL 2000 and doing some Pervasive-recommended modifications, 99% of
Status 2 issues disappear.

We have run into them here when people were working in the Btrieve
files during backups.  That's the *only* time we get them.  We do have
TURBODIS loaded.

Tom Kustner
Emjay Corp. - A Wells Fargo Company

Any opinions are strictly my own and not necessarily those of Wells Fargo.

I have a file that has about 1.3 million records in it that has given status 2's
twice in the last month since we upgraded our server from 3.12/6.10c to
5.0/6.10f.  I did not even think that the errors could be "phantom" - so I went
through the whole BUTIL -recover/clone/load process on the server.  Since this
is the customer database, the whole A/R and customer service departments were
down for the 6 hours it took to rebuild.  When the rebuild was complete, the
file would be a few hundred records short.  I wrote an audit program to try to
find the missing data, and consistently - the rebuild process tosses only the
most recent records.  This leads me to believe that this is a caching problem.
So my questions are:

1) Do you think that if we disable the Btrieve cache, this problem will go away
or be minimized?
2) Can I downgrade to v6.10c on a NW5 server - or do I need an NDS aware version
of Btrieve?
3) I have acquired PSQL.2000 - will this solve this problem, and if so, how
hairy an upgrade is it?

We are running an old DOS based Btrieve app developed in house (in Magic PC
v3.5).  We are moving to Magic v8.3 - but we will have to spend some time in
v5.7.  Due to the DOS based status - I thought the error 2's were occurring
because user's were not closing down the app correctly from the Windows
workstation - leaving the customer database in an unknown state.  The next time
the error 2 pops up - I'm going to try the rename/copy, the BSTOP/BSTART and the
Down server method.

If anyone finds a work around, I'd love to hear about it!

David

--
David P. Blum
Krane Products, Inc.
4800 North Federal Hwy
Suite 300E
Boca Raton, FL 33431
tel 561-362-5902
fax 561-362-8893

Hello David.
I would like to share some my experience, maybe it will be useful for
somebody...
I had 2 machines with Netware 4.10 as file and Btrieve servers.
Last year when I had to think about famous y2k problem, I thought about
upgrading
to 5.x or so, but after some reading/asking friends/etc I've decided to
upgrade my
old Netware 3.11 licence to 3.20 and use it as Btrieve-only server (file
server is
another issue for another newsgroup). RAM is 32Mb (it's old ALR Pentium
100 with SCSI drives),
60 users with 20+ simultaneously working. Server has 100 Mbit NIC,
workstations - 10 Mbit.  And all it works great, no status 2 or any
other
problems so far. Right now uptime is 146 days, and Btrieve.nlm was not
reloaded
during this time.
--

Quote:>2) Can I downgrade to v6.10c on a NW5 server - or do I need an NDS aware version
>of Btrieve?

Btrieve 6.x is not supported by Pervasive on NetWare 5, because
NetWare 5 was not out when 6.x was first released (1995).

Quote:>3) I have acquired PSQL.2000 - will this solve this problem, and if so, how
>hairy an upgrade is it?

We run Btrieve 6.15, but the files are still in Btrieve 5.x format.
We plan to upgrade to P.SQL 2000 later this year.  My impression from
our vendor is that the upgrade is pretty uneventful.  However, if we
want to get speed advantages, we will want to rebuild the files in
P.SQL format and that will add anywhere from 10-40% to the size of the
files, based on what the vendor has told us.

I cannot otherwise speak about P.SQL 7 or P.SQL 2000 and their
stability relative to earlier versions of Btrieve.

Tom Kustner
Emjay Corp. - A Wells Fargo Company

Any opinions are strictly my own and not necessarily those of Wells Fargo.

Unfortunately I have not read the entire thread, but heres my 2 cents. Way
back in the Netware 4.11 era I experienced the same problems with phantom
error 2's. As it turns out it had to deal with Netwares Turbo FAT Cache
(Thats why rebooting the server fixes the problem). If you are using Netware
4.11 let me know and I have the patches for the file. I am not sure if the
problem was fixed in Netware 5.

Actually, the problem WAS fixed in NetWare 5.  However, another "Phantom" status
2 has been occurring, especially under heavy load.  This one can occur on either
NetWare 4.x or NetWare 5.x, and is a bug in the NetWare ReadFile() API call.
Periodically, when called by multiple threads of the same application (or
perhaps multiple threads, period) it can return a successful status code, but
return no data.  Btrieve sees this as a status 2 error as well.

There is currently no NetWare fix (like TURBOD.EXE for the Turbo FAT Problem),
but Pervasive has provided workarounds in the latest service packs of 7.x and
7.5.  Check the readme files for "File IO Mutex".
 Goldstar Software Inc.
 Building on Btrieve(R) for the Future(SM)
 Bill Bach

 www.goldstarsoftware.com

Hope this info helps...
 Goldstar Software Inc.
 Building on Btrieve(R) for the Future(SM)
 Bill Bach

 www.goldstarsoftware.com
 *** Pervasive.SQL Service & Support Classes ***
 January 26-28, 2000; March 8-10, 2000
 See our web site for details!

Disabling the Btrieve cache will not help, since the phantom corruption problems are
with NetWare's cache instead.  Your Btrieve cache should be rather large to support
many users adequately -- expect 16MB as a minimum for 20+ users, and lean towards
32MB or 64MB if you can.  This will improve performance -- provided Netware has lots
of free memory.

Quote:> 2) Can I downgrade to v6.10c on a NW5 server - or do I need an NDS aware version
> of Btrieve?

6.10f is really only 6.10c with 4 bug fixes.  It is NOT NDS-aware in the slightest.

Quote:> 3) I have acquired PSQL.2000 - will this solve this problem, and if so, how
> hairy an upgrade is it?

Pervasive.SQL 2000 will have NDS-aware components, addressing #2 above.  If the
ReadFile() api is your problem, then you should be able to squash this problem with
the File IO Mutex option in PSQL2000 Service Pack 1.  Upgrading is fairly easy -- if
you have TCP/IP already running.  If not, get it running first.  If you can't,
install will be chock full o' workarounds.  Remember to save a backup of your SYSTEM
directory so that you can go back if needed.

Quote:> We are running an old DOS based Btrieve app developed in house (in Magic PC
> v3.5).  We are moving to Magic v8.3 - but we will have to spend some time in
> v5.7.  Due to the DOS based status - I thought the error 2's were occurring
> because user's were not closing down the app correctly from the Windows
> workstation - leaving the customer database in an unknown state.  The next time
> the error 2 pops up - I'm going to try the rename/copy, the BSTOP/BSTART and the
> Down server method.

NetWare 5.x doesn't suffer from the TurboFAT cache problem like NW4.x does, but
restarting the server should address ReadFile().  Whenever you have a server engine,
there is nothing a workstation can do to corrupt data files at the Btrieve level.
(Of course, bad application-level data is always possible.)

Quote:>Actually, the problem WAS fixed in NetWare 5.  However, another "Phantom" status
>2 has been occurring, especially under heavy load.  This one can occur on either
>NetWare 4.x or NetWare 5.x, and is a bug in the NetWare ReadFile() API call.
>Periodically, when called by multiple threads of the same application (or
>perhaps multiple threads, period) it can return a successful status code, but
>return no data.  Btrieve sees this as a status 2 error as well.

>There is currently no NetWare fix (like TURBOD.EXE for the Turbo FAT Problem),
>but Pervasive has provided workarounds in the latest service packs of 7.x and
>7.5.  Check the readme files for "File IO Mutex".

Bill,

Thank you *very* much for the information.  Our vendor had led us to
believe similar things, but we weren't aware of the "heavy load"
Status 2.  We have seen this when trying to use our Btrieve server
during backups.

We have also been told, as you mentioned above, the P.SQL2000 SP1
workarounds the problem.

Tom Kustner
Emjay Corp. - A Wells Fargo Company

Any opinions are strictly my own and not necessarily those of Wells Fargo.