Bad runtime object reference (Error 21) when run through incremental build. Please help.

[Former Member]

Hi,

Let me brief about my application before ask the question. In our application, we build patch and deploy at client machine. For building patch, we have a library upatch.pbl. This library is only for patch items. whenever we work on defect any released version. We work on object and move it to upatch library.

Once done, we build upatch library using incremental build. Once build is done, we deploy this upatch.pbd at client machine. This update.pbd resides at top in library list so that changed object takes preference in the application. Now the problem is whenever we run the application, we get bad runtime object reference error and application crashes. One workaround, I know is to add reference objects in upatch library and again build the incremental build. We don't know which reference may fail during running the application. We don't get this issue in development mode (running through pbls).

We can not know which reference is failing until we thoroughtly test the whole process. I don't want to increase the size of the upatch pbls (by adding reference objects).

What is the best way to avoid this bad runtime object reference issue. We can't run the full build otherwise we would have to deploy the whole pbds at client machine.

Please help me. I am attaching the error which we get when run the applications.

Please help.

Thanks,

Vipin

469-3058208

[Former Member]

Hi,

If you want to deploy an updated pbl and not an entire application then that is not guaranteed to work,

because objects are dependent on each other.

It is that way since, I believe, PowerBuilder 4 or 5.

If an object needs to call an object or property of a different object then it already knows where to call it. But if you have changed the object or the object in the already deployed app is different from the one you compile against, then you have a problem because the functions might be at a different place.

That was an issue at the time, but there was also a solution introduced at the same time (although maybe not intentionally) by which you can make sort of remote function calls like com calls to other objects. These are the dynamic function calls.

If you want to call a function from an object that may have changed then the use of the dynamic keyword is mandatory. With that keyword added functions will be looked up by its name and no longer looked up by its address and it will be a call more in the style of com, j2ee or corba (remote object calls.

Ben

[Former Member]

Hi Vipin;

  You can get away with a PBD build for one PBL if the objects inside are concrete (working) level components. If the classes in the PBL are ancestors to working level descendants then this WILL create an unstable build.

    The reason for this problem is when new or revised instance or shared variables are added or revised. PB then compiles a work area for these variable pools. The ancestor variable pool definition is then genetically passed done to the descendants. However, these descendants must then be recompiled in their respective PBL/PBD's. If not, there then becomes a memory mapping disconnect between the ancestor & descent.

   Once that happens, your application will become unstable. The only way around this is to do a full build/compile of all your PBL/PBD's in order to have PB sort out this variable memory mapping issue.

HTH

Regards ... Chris

[Former Member]

Chris,

What an explanation. I got it now. Thanks for the detailed reason. This problem happens only with Powerbuilder. Other desktop application like VB does not have such kind of issue.

Sybase (now SAP) should think about this problem.

Thanks once again Chris.

[former_member190719]

Actually, the process you use is one we've used for years to deploy "EBFs" to our customers.  We store the update PBD in the database and have it downloaded and installed on the users machine and added to the top of the library path.  When we do another update, we update the EBF table with the updated PBD and it replaces the last one.  It's worked quite well for us.  But you do have to include descendant objects in the PBD.  Its not just instance variables, PB descendants also have pointers back to object level functions in their ancestors that are affected when you modify the ancestor.  You have to deploy the descendants or else you'll get a mismatch there as well.

[Former Member]

Hi Vipin;

   You are most welcome.

  Actually, it will now be Appeon's problem after today's announcement ....

Regards ... Chris

[Former Member]

I don't see anything being done about this. It would require a total revamp of how PBD files are created. Since there is a simple work around, there is no good reason to do anything. There are plenty of other improvements that are more important.

[former_member190719]

When you change an object, you'll need to include the objects that reference it (particularly descendants) in that update.pbl as well.  That's they way it is.

[Former Member]

Hi Bruce,

Thanks for your prompt reply. I was surfing on google to find the solution for this. I found one site where it has been said that adding reference object in pbr file while making build may solve this issue. Is this correct?

So there is no other way except to add the descendent object in patch library.

[Former Member]

The .pbr file is primarily for including image files. You can use it to specify DataWindow objects that are assigned to a DataWindow control or Datastore at runtime.

If you do an Incremental deploy, it should only generate new PBD files for the libraries containing an object that needed to be regenerated.

With the speed of company networks or the Internet these days, I don't see why you wouldn't just update all the files. It would be a lot simpler.

[Former Member]

I understand updating all will solve the reference issue but we update all files once in a year in a new product version release.