0

I have an app which works great in the development environment but misbehaves when deployed as an EXE. When I click deploy and make an EXE, all of my queries which are run through DataStore objects succeed (SQLCode 0) but return zero rows. Out of frustration I changed to visible datawindows and it magically worked again under an EXE. So I made the datawindows invisible and it continued to work. This is just bizarre. I have another powerbuilder app which is much larger, uses lots of DataStore objects (on the same database) and those work great.

DataStore ds_wacn
ds_wacn  = create datastore
ds_wacn.DataObject = 'd_plateaccessions'
ds_wacn.SetTransObject(SQLCA)
ds_wacn.Retrieve(sLoad, iPlate)
IF SQLCA.SQLCode < 0 then ...
//  Succeeds in development, fetches zero rows under EXE

dw_wacn.SetTransObject(SQLCA)
dw_wacn.Retrieve(sLoad, iPlate)
IF SQLCA.SQLCode < 0 then ...
// Succeeds in development and in EXE

I was very careful to make sure that the app that works and the one that fails are using the same settings to connect to the database (but still could be a problem there). This is Powerbuilder 11.5.1

user922020
  • 712
  • 6
  • 12

2 Answers2

4

Very likely your DataWindow object isn't being compiled into the EXE.

When you compile an EXE, PowerBuilder starts at the Application object and intelligently tries to determine which objects should be included. Since d_plateaccessions is only referenced in a string in a script, it isn't included.

There are two ways around this.

You can create a PBD for the PBL containing the DataWindow. PBD creation blindly includes all objects in the PBL. This method is quite popular, and many people just mark all their PBLs for PBD creation and deploy the PBDs.

You can alternatively create a PBR for the EXE, telling the compiler to force certain DataWindows and graphic files into the EXE. If you really want a single EXE, but don't want the effort of building an appropriate PBR, you can use PBL Peeper to generate PBRs and scripts to force all DataWindows and objects (and find all relevant graphics) into a compiled EXE, using the PBR Builder Plus report.

Good luck,

Terry.

Terry
  • 6,160
  • 17
  • 16
  • Dang, can't vote you up (lack reputation). Yep. This is it. The DataStore objects were introduced at the same time as the queries. If only ds_wacn.DataObject = 'd_plateaccessions' would have thrown an error... I can't tell you how many times I have had a mispelling which causes a datastore or runtime modified datawindow to do absolutely nothing. Of course if it had told me "cannot create datawindow, DataObject does not exist" I would have been just as baffled! Compiler optimization mayhem hasn't really been a front-brain thought since C++ in the 90's. – user922020 Dec 05 '13 at 20:02
  • A hat with a propeller? Are you the technokitten that made PBL Peeper? That product has saved my bacon dozens of times. – user922020 Dec 05 '13 at 20:09
  • Well, I'm the one with fingers that the techno-kitten uses, yes. (Keyboards are a plague on the feline IT world.) Good to hear it's helped. – Terry Dec 05 '13 at 20:11
  • The DataStore does return an error. Retrieve returns -1 when there's no DataWindow object. You normally only check the Transaction object when an error occurs. You can make the DataStore more goof-proof by inheriting a user object from DataStore and adding an of_setDataObject method. This can check that there's actually an object after setting the object name. – Hugh Brackett Dec 06 '13 at 18:58
0

I have a problem with your first 4 rows.

DataStore ds_wacn
ds_wacn.DataObject = 'd_plateaccessions'
ds_wacn.SetTransObject(SQLCA)
dw_wacn.Retrieve(sLoad, iPlate)

Do you really retrieve on dw_wacn instead of ds_wacn?

And there isn't "create" for your local datastore. I don't use frenquently local datastore but in this case the code is like this in our program

dataStore ds_myDs
ds_myDds  = create datastore
ds_myDds.DataObject = 'myDataObject'
ds_myDds.SetTransObject(SQLCA)
ds_myDds.Retrieve( /*arguments or not*/)    

/*
some code    
*/

destroy ds_myDs
  • I distilled the question from a lot of back and forth between datastore and a dropped on form datawindow. It caused typos. Fixed for posterity. – user922020 Jan 03 '14 at 20:16