Contributed by Sharon
Here are the top reasons why you would get a GPF while running your
- In the development environment, check your PowerBuilder Search Path -
Are all eight PFC/PFE PBLs there (pfcapsrv.pbl, pfcdwsrv.pbl, pfcmain.pbl, pfcwnsrv.pbl,
pfeapsrv.pbl, pfedwsrv.pbl, pfemain.pbl, pfewnsrv.pbl)? Are all other PBLs there, too?
Also, make it a practice to go out of PB and back in whenever you change your PB Search
Path. There were some bugs in 5.0.
- Running an EXE, check to make sure that all of your application's PBDs/DLLs are
in your application's path. After a build, you must go round up all of the PBDs/DLLs. Each
one can be found in the directory where its source PBL was located. Also make sure that
the correct version of the PowerBuilder runtime DLLs is in your application's path.
- Are you running the same version of PowerBuilder as you are running the
PFC version? For each 5.0.## release, you must run a full rebuild to regenerate all
objects to the newer PowerBuilder version. Double check to make sure that you are running
the same version of PowerBuilder and PFC source. (Check the about for PB, and check the
instance varibles in pfc_n_cst_debug for PFC.)
- Try running a full rebuild. Running a full rebuild will properly
regenerate all of your objects, in the proper hierarchical order. It should also handle
regenerating objects which reference each other, such as regenerating the window and tab
objects when a tabpage object changes.
- For 16-bit machines... Are you running low on GDI resources? Has your
application been "Halt Close"ing lately? Have you gone out of windows and back
in after every GPF? Memory management is poor in 16-bit operating systems. Try to avoid
having your program "Halt Close". If you are running an MDI frame application,
close the frame instead. But if you must perform a "Halt Close", at least first
execute the destructor event on the Application Manager. This will ensure that the
services will be destroyed.
- Is your PFC application not closing by itself? Some people discovered
that that if you have a datastore that your application was using that has not yet been
destroyed, your application will not close naturally. A common fault is calling the Error
Service's of_LoadPredefinedMsg() and then not destroying the Error service before trying
to close your application.
- Are you reading in any of your DataWindows in 'async' mode, meaning
that you have any code in any of your DWs' RetrieveRow events?
or does your transobject somehow have SQLCA.dbParm = "Async = 1" set? or have
you specified dw_1.Modify("DataWindow.Retrieve.AsNeeded=Yes")? If so, and if you
close your window "too fast" (before the retrieves complete without calling a
DBCancel), your program will GPF.
- Are you somehow fragmenting memory unknowingly, by say perhaps calling
a lot of 'autoinstaniated' NVOs? This can happen when say calling a lot of PFC
n_cst_string functions like of_PadLeft(), all in one big string statement. The GPFs were
flaky and hard to pinpoint to exactly what was actually causing it, since the
GPFs seemed random.
For other GPF resolution tips see the Faxline docuents below:
Contributed by PFCGuide staff, except
where noted otherwise.
PFCGuide is sponsored by Dynamic Technology Group
The information provided is for advice only and not to be considered a contract or a
liability against Dynamic Technology Group.
Last revised: February 15, 2004 03:58 AM.