0
votes

I have a very strange situation with Powerbuilder 12.1. I have two issues that may be related - mainly because it's for the exact same datawindow report.

Issue #1: Somehow and somewhere, the capability to display contents of a DataWindow during Debug and Runtime has been lost. You no longer can see the contents of a datawindow during debug and runtime.

BUT when you go into the datawindow in Design mode, it prompts you for the values for the parameters it needs, the contents are displayed just fine.

EDIT: RESOLVED. This was due to a Powerbuilder using an integer instead of a long variable. The identity ID in the database exceeded the upper bound of a PowerBuilder 16 bit integer (32,767). I updated the logic to use long, and that resolved this issue #1.

ISSUE #2:

When I ran the report code using the same datawindow mentioned in Issue #1 above in debug mode to generate a new report file, it worked -- in DEBUG mode only. Runtime failed -- I was getting a -1 error during runtime for the exact same call.

Here's the code snippet using DATASTORE (I already tried DataWindow just to see and that too failed):

  datastore lds_blarney_report
  lds_blarney_report = CREATE datastore

  iw_main_sheet.wf_write_log("Retrieving report data")

  lds_blarney_report.dataobject = as_datawindow
  lds_blarney_report.SetTransObject(sqlca)
  ll_ret = lds_blarney_report.retrieve(al_file_no, "%")

In DEBUG mode: the last line returns some positive non-zero value and a report is generated In RUNTIME mode: the last line returns -1 (according to Sybase, Retrieve returns the number of rows displayed (that is, rows in the primary buffer) if it succeeds and -1 if it fails. If there is no DataWindow object assigned to the DataWindow control or DataStore, this method returns -1.)

So why did retrieval work in Debug time in creating a new report file, but fail in runtime?

2
Have you run a database trace while testing this to see what the SQL being sent to the DB looks like? - Matt Balent
Issue 2: By "runtime", do you mean by running compiled executables, as opposed to running inside of the IDE? - Terry
Yes Terry. RunTime = compiled executables. Debug = running inside of the IDE. - tobbiefox
Matt, yes I did. The database trace was fine; it had all the correct parameters. - tobbiefox

2 Answers

1
votes

It sounds like the DW you're trying to load at runtime isn't compiled into the app.

There are several possiblities as to how this would happen:

  1. Your PBR file no longer includes the runtime referenced datawindow object. It needs to be re-added.
  2. The PBR file never had a reference to the DW, but there was an absolute reference somewhere that caused it to be included. That reference is now gone and the EXE doesn't include the DW anymore.
  3. The PBL containing the DW was once a PBD, but is now being compiled into the app. This means that no runtime assignments to datawindows that were in that PBD will work without inclusion in the APP PBR file OR explicit assigns in painters.

Hope this helps.

0
votes

I was able to solve this, but the resolution did not answer the pressing question of "Why did the previous code, which worked just fine for years, decide to stop working?"

Previously, the code passed a string parameter identifying a datastore to the local datastore's dataobject parameter. That was enough to use the SQL query included in the datastore to extract the needed data to generate a report (via SaveAs). Here's the original code:

datastore lds_blarney_report
lds_blarney_report = CREATE datastore

iw_main_sheet.wf_write_log("Retrieving report data")

lds_blarney_report.dataobject = as_datawindow
lds_blarney_report.SetTransObject(sqlca)
ll_ret = lds_blarney_report.retrieve(al_file_no)

Somehow, somewhere, the code got broken such that it will work only in IDE/Debug, but fail with a -1 error during runtime (compiled executable).

I was able to solve this by creating a datastore object (n_ds_*) in the PBL project (the datawindow is in another PBL), then going about using it. Here's the updated code...

NOTE:  n_ds_no_load_blarney was created in the project with a 
       dataWindow reference to d_blarney in a different library.

n_ds_no_load_blarney lds_no_load_blarney

iw_main_sheet.wf_write_log("Retrieving report data") 

lds_no_load_blarney = CREATE n_ds_no_load_blarney
lds_no_load_blarney.setTransObject(SQLCA)
ll_ret = lds_no_load_blarney.retrieve(al_file_no)

As you can see, the code appears nearly identical although there are differences. That said, I still don't know why the 2nd code fragment worked, and not the 1st one. Why did it stop working now after years of working just fine? Maybe it's so obvious that it's Times Squaring over my head. :)

Your help is appreciated.

EDIT: EDIT:

I am a boneheaded conehead, worthy of Dan Aykroyd's Conehead character. The reason why all this dung hit the fan is because we moved the Powerbuilder development machine to a new workstation (new OS, new everything). As a result of that move, the Powerbuilder development location changed drive letters.

This meant that we forgot to update the PBR file for each and every Powerbuilder project to point to the updated location on a new drive. Once I did that, all these issues reported here went away. Interesting.