Hi Lucia;

  If this happens consistently, I would recommend using the PB IDE's "Debugger" on the PowerScript code that is modifying the DWO's properties & behaviour. By "stepping through" your related code you should be able to locate the problematic statement.

HTH

Regards ... Chris

The problem is not as simple as it looks. Running from Debug does not give any error. In the previous version of PB (10.2) there was no problem and the feature was not changed. We just migrated the code to PB 20017R3

The window is a response type and displays data in a datawindow (DB is SQL). The datastore is changed dynamically, the select and its properties. This response window is called from different modules and the datastore is slightly different, same for the SQL syntax. If just launching the application, call the window from module A => the exe stops working  (see pic)

The other scenario: launch the application and call the same window from module B(ex)=> data is displayed, no error. Then call the the window from module A => this time is not crashing anymore.We can call it n time and will not crash. But if exit the app and return to module A calling the Window => same crash

My guess is that first time the SQL is taking some time to build the plan and data retrieval is a bit longer; after same SQL plan is used and response is fast.

After migrating to new PB version we had to add some SetRedraw (false) to improve display time although some comments are stating that is not a good practice.

Hi Lucia, for this issue I recommend opening a support ticket.  But without reproducible test case Appeon support can’t help.

We are experiencing the same issue in one of the production environment. As the issue does not happen in any of our development machines. Can someone share an ideas or steps to find the root cause of the issue will help to resolve the issue.

Why would SetRedraw(false) be bad practice? We use it everywhere all the time. You just have to be careful to set it back to true before any popups like messageboxes and / or other windows opening.

 Is your executable "machine code" or interpreted (PBD?). Try PBD if not. Is the datastore present in a PBR file if not PBD used?

This might sound funny but "one thing you could try" is to make sure the exported datastore starts with "release 17;". Migration does not change the version. Best thing to do would be to edit the dw (not the source) and then just move anything a pixel to the right and then back to the left (or something similar), just to be able to "save" the datastore. This way you ensure all new attributes are present in the new format. (might not help but surely won't harm).

Also make sure there's a default printer on the PC assigned in windows.

Another thing: Does your module A maybe have another datastore with a long similar name? We have had sometimes problems of powerbuilder "confusing" one with another if that was the case. Make sure there's some difference somewhere in the let's say first 18 characters in the naming if this is applies to your module A. (I don't remember the exact amount of characters when that possible problem might occur).

Nothing else I can come up with at this moment.

Good luck.

Hi Lucia，

Due to that we can’t reproduce this issue locally, it is hard for us to find out the root cause of it for now.

Can you provide a small reproducible case for us? If yes, please go to Appeon Support Ticket system(https://www.appeon.com/standardsupport/newbug) to open a new ticket with this small case thus it can be properly received and tracked.

Regards,

Ken

Hi Lucia;

    Just an FYI that PB 2017 R3 MR02 was released today (build 1915). If you can, you might want to try this latest LTS build of PB 2017 and see if that helps your situation.

FYI: https://www.appeon.com/company/news/powerbuilder-2017-r3-and-infomaker-2017-r3-mr-1915-released.html

Regards ... Chris

Hi Lucia;

   Here is how I run multiple builds of any PB version. I have been using this technique successfully for over 2 decades, as follows:

My current actual setup for PB 2017 R2 & R3 switching (build 1880 & 1915)

1. Copy the current "PowerBuilder 17.0" folder to "PowerBuilder 17.0 - Bnnnn" (my personal convention)
2. Copy the current "Shared" folder to "Shared - Bnnnn"
3. Install the next version / build of PB 2017Rx
4. Copy the updated "PowerBuilder 17.0" folder to "PowerBuilder 17.0 - Bnnnn" (backup)
5. Copy the updated "Shared" folder to "Shared - Bnnnn"

Now to activate any version / build - copy the Bnnnn folders back to their primary names. To switch back - delete the primary folder names and copy the other Bnnnn folders back to their primary names.

Tip: For faster switching, just rename the Bnnnn folders back to their primary names. If you forget what version/build your on, just start the IDE and check the version/build in the IDE's bottom rh-bottom corner when it starts.

HTH

Regards ... Chris

PS: Same approach for PB2019Rx as well.

was there any resolve to this?  We have experience similar issues - our program is just 'vanishing', and windows is reporting it is the pbdwe19.dll or the comctl.dll.

Jeff/

Hi Jeff, I had pretty much the exact same error as the original poster, so it didn't involve comctl.dll like yours.  But in my case it was an application to create and send emails.  It would work for around 160 of them, and after that it would crash out with the pbdwe170.dll Exception code: 0xc0000005 error.

It turned out my issue was with a datastore that I was dynamically creating in an object function but not destroying.  After I added the destroy line in it seems to work fine.  From that I'd assumed my error was either memory or garbage collection related.