invalid page fault @kernel32

[Arnie]

I have a form with 2 sub forms: sub form 1 linked to main form. subform 2 linked to subform 1. sometimes this form works just fine and at other times I get the message about the invalid page fault in kernel32.dll. Can't figure this one out.

 

[The_Doc_Man]

There are about a thousand reasons why this would occur, but the first one on the list is: Have you applied the latest Service Pack to your version of Windows since you last installed any new products? If not, I would strongly suggest doing so.

Second possibility. Do you have manufacturer's diagnostics on your machine already? (For example, COMPAQ machines have an icon in Run >> Settings >> Control Panel that lets you run your diagnostics.) If you can do so, run a memory test on your system. It shouldn't take very long.

Third possibility. Do these forms include home-grown code? And in particular, do they have class modules that attempt ActiveX or Win32API calls directly? (If so, one of the calls may be using an actual parameter in the wrong mode of argument passage for the given formal parameter.)

Fourth possibility. Have you a good virus checker? If so, make sure it is properly updated, then run a full scan, all files.

If none of the above work, ask again.

 

[Arnie]

I have a form with 2 sub forms: sub form 1 linked to main form. subform 2 linked to subform 1. sometimes this form works just fine and at other times I get the message about the invalid page fault in kernel32.dll. Can't figure this one out.

Thanks.
Tried all of the above.
Read somewhere that when moving too fast to next records in form that is based on a query that the querying can't keep up. Don't know if I said that right, but I haven't had the problem since slowing down when reviewing records. I'm in the stage of developing this app and I doubt that in the real world the users would be moving among records that fast.

 

[The_Doc_Man]

Read somewhere that when moving too fast to next records in form that is based on a query that the querying can't keep up.

As far as I understand this, you only run into this problem if you have an ODBC-linked database. A purely local database can't move 'too fast.' - all operations are synchronous.