TD092397
asked on
VB5 using Btrieve
I receive an intermittent 'Invalid Page Fault' when accessing the Btrieve engine from a VB5 project.
I am using the 1996 version of the Btrieve WBTRV32.DLL
Funnily enough, the error doesn't just happen on the actual BtrCall calls, it often happens on an End Sub and various other places.
Changing the ByVal's in the actual call has an effect. However, I have not been able to find a combination that totally eliminates the problem.
The fault does not necessarily happen the first time the code is run. Sometimes it takes 12 runs for it to happen. Once it took 44 times.
Help !
I am using the 1996 version of the Btrieve WBTRV32.DLL
Funnily enough, the error doesn't just happen on the actual BtrCall calls, it often happens on an End Sub and various other places.
Changing the ByVal's in the actual call has an effect. However, I have not been able to find a combination that totally eliminates the problem.
The fault does not necessarily happen the first time the code is run. Sometimes it takes 12 runs for it to happen. Once it took 44 times.
Help !
What Access method are you using? RDO? Are you using the Pervasive ODBC driver? Is the Jet engine involved? Please tell me more about the configuration involved. thx!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks.
Funnily enough our support manager tried it out yesterday afternoon and it didn't help. I've tried it as well. No go.
I'm not using RDO, ODBC or the Jet engine. I use a function declaration (BtrCall) and maintain all aspects of a particular file within a class instance.
To give you an idea:
The sample code that comes with the developers' kit works. Which peed me off no end ! So I changed it.
First I remmed the code that creates the file. Then I put the rest in a 0-100 loop (remember you have to run it a few times).
It ran fine.
Second I changed the data buffer being passed to a fixed-length string of len = 585 instead of a user-defined type. Crash !
Unfortunately, changing my class to use a user-defined type doesn't help.
By the way, my background: I have been using VB for 4 years and Btrieve for 3 months. Just to give you an idea on what level you would need to talk to me. (Also I'm really stupid).
Thanks
Funnily enough our support manager tried it out yesterday afternoon and it didn't help. I've tried it as well. No go.
I'm not using RDO, ODBC or the Jet engine. I use a function declaration (BtrCall) and maintain all aspects of a particular file within a class instance.
To give you an idea:
The sample code that comes with the developers' kit works. Which peed me off no end ! So I changed it.
First I remmed the code that creates the file. Then I put the rest in a 0-100 loop (remember you have to run it a few times).
It ran fine.
Second I changed the data buffer being passed to a fixed-length string of len = 585 instead of a user-defined type. Crash !
Unfortunately, changing my class to use a user-defined type doesn't help.
By the way, my background: I have been using VB for 4 years and Btrieve for 3 months. Just to give you an idea on what level you would need to talk to me. (Also I'm really stupid).
Thanks
In these modern software environments, everybody is dumb, but few are honest enough to admit it! It's become a software minefield out there, with untested software issued by major suppliers desparately seeking plausible deniability! Stupid hidden workarounds to major disabling operating problems are proposed that still leave the program functionally unuseable, or unscalable to real world sized applications. I have been trying off and on to get acceptable performance from the btrieve ODBC using VB 4 and RDO, in order to perform massive extracts from very large btrieve files for loading data warehose systems, and have been continually frustrated by an inability to achieve acceptable performance. This is particularly frustrating, because I know that native btrieve access under DOS is blazingly fast for what I'm trying to do.
You have to know the page fault is in the .DLL, because that operates in your own address space under windows. It's only a matter of timing that positions the page fault in any place in your code.
You might check out your BTI.INI file in your windows directory, there are a number of options there that might mask the problem enough to make it useable. Also the readme files have some information on increasing a few parameters that might help as well. Let me know if you find any good performance hints/fixes. I'm probably dumber than you on this one. cymbolic@aol.com or doug.taylor@hboc.com
thx!
You have to know the page fault is in the .DLL, because that operates in your own address space under windows. It's only a matter of timing that positions the page fault in any place in your code.
You might check out your BTI.INI file in your windows directory, there are a number of options there that might mask the problem enough to make it useable. Also the readme files have some information on increasing a few parameters that might help as well. Let me know if you find any good performance hints/fixes. I'm probably dumber than you on this one. cymbolic@aol.com or doug.taylor@hboc.com
thx!
P.S. go to www.pervasive-sw.com and check out the article in the tech papers section called "Advanced Tuning for the Microkernal Engine" It details the option settings and their meanings. Also, I noted one reference under page fault regarding applications with out enough stack space causing page faults. Hey, you aren't running any recursive routines are you? That could cramp your stack space style in a hurry!
ASKER
The problem 'seems' to be solved. There were three different factors involved:
1.) If the data buffer is a user-defined type, do not use ByVal in the call. Otherwise, use it. This makes no sense, considering the data buffer needs to have info returned to it, but hey ! that's life.
2.) The key number argument in the Open call. This is weird. If you declare the variable you pass through explicitly as an integer, then you crash. Use DefInt A-Z, declare the variable with no type specification, and it works. ???
3.) The variable you pass through as the data buffer in the open call has to be the same variable as is used in the rest of the calls. It also has to have module-level scope.
These may not be right (they certainly don't make much sense), but ensuring these 3 issues were dealt with correctly has solved my problem. It took me 3 weeks to figure it out though, so I hope this helps someone else from going thru the same S***.
Thanks very much for your help, cymbolic. Sorry I can't credit you with solving the problem. Hope you manage to sort yours out.
p.s. What do I do now with this problem ?
1.) If the data buffer is a user-defined type, do not use ByVal in the call. Otherwise, use it. This makes no sense, considering the data buffer needs to have info returned to it, but hey ! that's life.
2.) The key number argument in the Open call. This is weird. If you declare the variable you pass through explicitly as an integer, then you crash. Use DefInt A-Z, declare the variable with no type specification, and it works. ???
3.) The variable you pass through as the data buffer in the open call has to be the same variable as is used in the rest of the calls. It also has to have module-level scope.
These may not be right (they certainly don't make much sense), but ensuring these 3 issues were dealt with correctly has solved my problem. It took me 3 weeks to figure it out though, so I hope this helps someone else from going thru the same S***.
Thanks very much for your help, cymbolic. Sorry I can't credit you with solving the problem. Hope you manage to sort yours out.
p.s. What do I do now with this problem ?
Geez..you're right, none of these changes are intuitive! How did you figure them out? I've seldom found anything really useable on the pervasive-sw site.
I think the easiest tning to do is accept the answer, but adjust the points down to zero. That way the slate's cleared, but the info sticks around for others to view.
I think the easiest tning to do is accept the answer, but adjust the points down to zero. That way the slate's cleared, but the info sticks around for others to view.