Hi everyone (Bill haha),
I am getting RPC issues on my NT box...lat time this happened we had
Btrieve issues although not root caused by Btrieve.
Now we are getting those pesky RPC problems again and the PVSW.LOG is
full of hex dumps!
I googled this already and from what I see the problematic IP address
is 00.00.00.00??
I wonder if this means that it is coming from the host where Btrieve is
loaded?
Running Version 7 with all service packs on NT w/sp6a
Any idea what the command is, data...any thing else that could be a
clue?
we did run out of disk space

Here is the dump (Edited slightly for Clarity sake):

11-21-2005 11:50:48 NTMKDE 00000081 NTDBSMGR.EXE
<SERVERNAME> E An invalid request was
received. Hex dump follows
06a70010: 72 00 4b 00 00 00 30 00 d4 01 00 00 00 00 00 01
06a70020: 00 00 00 00 00 00 00 00 00 00 af 01 49 54 a9 01
06a70030: 5c 00 a7 06 00 00 3c 00 00 00 50 00 00 00 00 00
06a70040: 3c 00 00 00 42 00 1a 00 a7 06 76 61 ff ff ff ff
06a70050: ff ff ff ff ff ff ff ff 00 00 c5 00 0b 0b 13 08
06a70060: 05 44 0f 05 0d 0c 04 00 00 00 00 00 00 00 00 00
06a70070: 00 00 00 00 79 49 00 66 10 00 a7 06 10 00 a7 06

any insight into this hex puzzle would be greatly appreciated!

Thanks,

-Henry

Henry: (he he)

This message stems from a Btrieve 6.x Function call going into the
engine that is not quite formatted properly. IN this case, the message
appears to be formatted mostly correctly as a FileOpen request, but the
filename being passed in is garbage (is starts with "ff ff ff...".
Additionally, the request DOES seem to be coming from the local
computer (i.e. the server itself).

It's hard to say WHY this is coming in, but it could be a memory
problem on the server (i.e. corruption of some kind). You may wish to
try reinstalling the PSQL7 components & see if that helps. Perhaps a
DLL got mangled...
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - March, 2006 ***
*** Chicago: Pervasive DataExchange Class - March, 2006 ***

myfriendhenry (AT) yahoo (DOT) com wrote:

Thanks Bill!!
I beleive that we found the culprit. I turned off Anti-virus
protection on the database files and have not have another entry in the
log file since. This particular database is very large in comparison
to others that we have. It may have taken the Anti-virus engine a long
time to scan the db files especially since it is set to scan in
real-time for ALL changes to any file. Could probably leave the
nightly scan, but lose the real-time stuff.
Thanks again Bill.

-Henry

An Update!
Lest folks become misled...At times in our business we realize that we
didn't really find the cause at all. Happened this time. Turns out
that the problem crept up again even with the anti-virus turned off for
the DB files.
Apparently our s/w vendor who maintains some apps, rolled back to a
prev. version and the problem went away.
I know for sure that one of thier apps was locking some tables, but I
think the real issue is how they handle what actions are taken in
response when attempting access to a locked table in another app. I
highly suspect that they are in a tight loop hitting the DB until it
becomes unlocked...as that appears to be thier programming style.
This activity most likely ties up RPC and everything else that uses
RPC as I note that RPC is used by Pervasive.
I wish they would put some intelgence in thier apps instead of
aggressive repeated attempts in tight loops.
Oh well out of my control....

Thanks again Bill!

-Henry