This trick from Chris Pollach @Appeon is FANTASTIC!!
add a pb.ini to the folder of your executable
PB.ini
------------------
[DataStore Behavior]
UseHwnd=no
----------------------
- You are here:
-
Home
-
Q&A
-
Q&A
-
PowerBuilder
- Fix for random crash. Works for ALL pb versions including 2019 R3
-
Steen Jakobsen
- PowerBuilder
- Thursday, 18 February 2021 06:54 AM UTC
Comment
- Steen Jakobsen
- Thursday, 18 February 2021 17:11 PM UTC
No down side at all .. that is my experience over a 2 month production period. It simply makes your app rock solid specifically on Windows Server and having multiple instances running at the same time. I dont know why this is not implemented in PB. Someone mentioned that it was because you could potentially make your datastore visual and also some legacy dependency for EAServer. Why anyone would want to do that I do not get!!
If it was implemented in PB it could have saved med a TON of work.
But now thanks to Chris i'm hugging my datawindows and datastores all day long :-)
If it was implemented in PB it could have saved med a TON of work.
But now thanks to Chris i'm hugging my datawindows and datastores all day long :-)
- mike S
- Thursday, 25 February 2021 20:28 PM UTC
- Steen Jakobsen
- Friday, 26 February 2021 06:19 AM UTC
Hi,
This has nothing to do with pb.ini
For what it is worth all works 100% perfect now for me and I'm just so overwhelmingly grateful for the tip from Chris Pollach @Appeon
// Steen
ps.
I do NOT use this:
THIS.Reset() // Release buffers
THIS.DataObject = "" // Release DWO resources
Yield() // Let Garbage collection complete
This has nothing to do with pb.ini
For what it is worth all works 100% perfect now for me and I'm just so overwhelmingly grateful for the tip from Chris Pollach @Appeon
// Steen
ps.
I do NOT use this:
THIS.Reset() // Release buffers
THIS.DataObject = "" // Release DWO resources
Yield() // Let Garbage collection complete
There are no comments made yet.
Comment
- Steen Jakobsen
- Thursday, 18 February 2021 17:12 PM UTC
Great tips about the rest() etc.
Thanks again Chris. Your work and contribution is must appreciated.
//Steen
Thanks again Chris. Your work and contribution is must appreciated.
//Steen
- Benjamin Gaesslein
- Thursday, 25 February 2021 07:33 AM UTC
Putting this in the destructors for n_ds and u_dw base objects causes my application to crash. I assume it's because some DS/DW further down the inheritance chain has some code in the destructor that clashes with this.
- Miguel Leeuwe
- Thursday, 25 February 2021 09:18 AM UTC
That's probably a very good point Benjamin.
regards
regards
There are no comments made yet.
Comment
- Simone Olianti
- Wednesday, 24 February 2021 18:35 PM UTC
[DataStore Behavior]
UseHwnd=no
if i enable this on my pb.ini and starting my app from a compiled .EXE i'm getting trouble accessing external datastore migrated to snapdevelop web api and accessed via restclient. If i run it from the IDE it's working fine.
no idea why
UseHwnd=no
if i enable this on my pb.ini and starting my app from a compiled .EXE i'm getting trouble accessing external datastore migrated to snapdevelop web api and accessed via restclient. If i run it from the IDE it's working fine.
no idea why
- Chris Pollach @Appeon
- Wednesday, 24 February 2021 19:11 PM UTC
Hi Simone;
This does not make sense as the DS migrated to C# does not use this setting. It should not affect the C# code.
How is the DS in the PB App used (consumed) in conjunction with the C# Web API?
Regards ... Chris
This does not make sense as the DS migrated to C# does not use this setting. It should not affect the C# code.
How is the DS in the PB App used (consumed) in conjunction with the C# Web API?
Regards ... Chris
- Simone Olianti
- Thursday, 25 February 2021 10:20 AM UTC
hi Chris here is how i am accessing the datastore
RESTClient inv_RestClient
inv_RestClient = CREATE RESTClient
inv_RESTClient.SetRequestHeader ("Content-Type", "application/json;charset=UTF-8")
inv_RestClient.Setrequestheader( "Accept-Encoding", "gzip")
datastore dss
dss = create datastore
dss.dataobject='dss_startreg_new_find'
ls_Request_Url = ls_url+"startregnewfind/Retrieve?codaz=" + ls_codaz
inv_RestClient.retrieve(dss, ls_Request_Url)
if dss.rowcount( ) > 0 then
messagebox("SUCCESS!", "")
else
messagebox("FAILED!", "")
end if
destroy dss
destroy inv_RestClient
if i put the pb.ini in the client folder where is the app .exe the retrieve always failing. If i remove it, it's working
RESTClient inv_RestClient
inv_RestClient = CREATE RESTClient
inv_RESTClient.SetRequestHeader ("Content-Type", "application/json;charset=UTF-8")
inv_RestClient.Setrequestheader( "Accept-Encoding", "gzip")
datastore dss
dss = create datastore
dss.dataobject='dss_startreg_new_find'
ls_Request_Url = ls_url+"startregnewfind/Retrieve?codaz=" + ls_codaz
inv_RestClient.retrieve(dss, ls_Request_Url)
if dss.rowcount( ) > 0 then
messagebox("SUCCESS!", "")
else
messagebox("FAILED!", "")
end if
destroy dss
destroy inv_RestClient
if i put the pb.ini in the client folder where is the app .exe the retrieve always failing. If i remove it, it's working
There are no comments made yet.
Comment
- Miguel Leeuwe
- Thursday, 25 February 2021 01:03 AM UTC
YW Chris,
Yes, I'm taking the code out for now from our n_ds and u_dw. I'll only apply it when I run into trouble in specific situations. Maybe behavior of datawindows and datstores change and I'd rather not risk anything. For now our applications seem to do fine without it.
regards
Yes, I'm taking the code out for now from our n_ds and u_dw. I'll only apply it when I run into trouble in specific situations. Maybe behavior of datawindows and datstores change and I'd rather not risk anything. For now our applications seem to do fine without it.
regards
- mike S
- Thursday, 25 February 2021 12:31 PM UTC
@chris, yes, you can assign an invalid dataobject name without it changing syntax of the dw/ds control. this is EXTREMELY USEFUL by the way and MUST work this way for runtime security and customizations.
I set a 'fake' dataobject name when I load in a datawindow's syntax from a database blob. I use the dataobject name to let my application 'know' that it was loaded from syntax rather than from a regular stored datawindow. I call the dw.create( datawindowsyntax), then set the dataobject name with an identifier so the application knows the identify of the syntax.
In security and customization processing, you need to know the object - for a datawindow that would be the name which is stored in dataobject. So if you are loading it dynamically from stored syntax in the database you still need a unique name to make the security and customization work.
I set a 'fake' dataobject name when I load in a datawindow's syntax from a database blob. I use the dataobject name to let my application 'know' that it was loaded from syntax rather than from a regular stored datawindow. I call the dw.create( datawindowsyntax), then set the dataobject name with an identifier so the application knows the identify of the syntax.
In security and customization processing, you need to know the object - for a datawindow that would be the name which is stored in dataobject. So if you are loading it dynamically from stored syntax in the database you still need a unique name to make the security and customization work.
- mike S
- Thursday, 25 February 2021 13:02 PM UTC
Actually, i take that back. I set the 'invalid' dataobject name FIRST, and THEN create the datawindow from syntax. If you set the dataobject name after the create, it will (or at least used to) destroy the datawindow. I should have read my code first rather than try to remember details of something i did years ago.....
There are no comments made yet.
FWIW,
Interesting, when I use the 'correct' order of first doing a Reset() and then assigning the dataobject = "", it blows up in of_update_totals(), when exiting the app. I'm not using yield(). Here's the stack:
With the 'incorrect' order of doing first dataobject = "" and then the reset(), my stack looks like this and doesn't blow up, but the fact it's still passing through the function while the application seems to have been closed already, is a bit concerning: no local, instance or global variables, nothing shown on the stack, no way to inspect anything with QuickView. The app has obviously stopped already, but it still looks like I'm passing through this function:
Probably something we do wrong somewhere.
regards,
MiguelL
Comment
- Miguel Leeuwe
- Thursday, 25 February 2021 01:07 AM UTC
Small remak: I marked ll_rowcount = 0 in yellow, but to be honest that's irrelevant as it's not being assigned a value. The value is 0 though and that's why it's blowing up using [1] to access the row.
- Chris Pollach @Appeon
- Thursday, 25 February 2021 01:08 AM UTC
No, you should only be doing this on the DC / DS's "Destructor" event. ;-)
- Miguel Leeuwe
- Thursday, 25 February 2021 01:11 AM UTC
Yes that's were I was doing it ... Unless this is an answer on me commenting I would only use it in specific situations?
(like within of loop using datastores).
(like within of loop using datastores).
There are no comments made yet.
Comment
- Steen Jakobsen
- Thursday, 25 March 2021 06:49 AM UTC
I guess you are right. But the performance and stability for using this trick is x1000 the work to print from a DW control!
It has made a "night vs. day" change in the stability and performance and I have zero side effects. :-)
//Steen
It has made a "night vs. day" change in the stability and performance and I have zero side effects. :-)
//Steen
- Benjamin Gaesslein
- Thursday, 25 March 2021 11:37 AM UTC
The performance increase is indeed astonishing. But we're using many datastores to print reports from NWOs, there's no chance to convert all these pfc_print() calls to something else.
BUT I've managed to work around this and recreate the proper behaviour by overriding the pfc_print event of pfc_n_ds. My first idea was to create a datawindow, use datasharing and simply print the DW instead. But this doesn't work for several reasons; first of all a DW has to be created using OpenUserObject, which is not directly possible from an NVO. And datasharing will not share nested reports automatically.
What NVOs *can* do is open windows, which in turn *can* create DWs via OpenUserObject. So I've worked around the first problem by creating dummy window and Datawindow objects. Now pfc_print opens an invisible window, which opens the dummy DW, sets the dataobject to the one the DS uses and prints the DW via print(true,true). In the printstart event of the dummy DW, I do a printcancel() so it won't actually print. But all the settings from the print dialog are then written to the DW. Then I get the print attributes via describe, set them to the DS via modify and print the actual DS using print(false,false). Since the dummy DW print function always returns -1 in this case, the DW also has to have a boolean flag to track wether the printstart event actually fired or if the user pressed the cancel button on the print dialog.
Another caveat is that selecting a range of pages to print doesn't work this way, because the dummy DW is empty. This can also be worked around by reading the PageCount() from the DS and doing insertrow(0) on the dummy DW in a loop until its PageCount() value is equal.
All in all it works well and is indistinguishable from the regular printing behaviour.
BUT I've managed to work around this and recreate the proper behaviour by overriding the pfc_print event of pfc_n_ds. My first idea was to create a datawindow, use datasharing and simply print the DW instead. But this doesn't work for several reasons; first of all a DW has to be created using OpenUserObject, which is not directly possible from an NVO. And datasharing will not share nested reports automatically.
What NVOs *can* do is open windows, which in turn *can* create DWs via OpenUserObject. So I've worked around the first problem by creating dummy window and Datawindow objects. Now pfc_print opens an invisible window, which opens the dummy DW, sets the dataobject to the one the DS uses and prints the DW via print(true,true). In the printstart event of the dummy DW, I do a printcancel() so it won't actually print. But all the settings from the print dialog are then written to the DW. Then I get the print attributes via describe, set them to the DS via modify and print the actual DS using print(false,false). Since the dummy DW print function always returns -1 in this case, the DW also has to have a boolean flag to track wether the printstart event actually fired or if the user pressed the cancel button on the print dialog.
Another caveat is that selecting a range of pages to print doesn't work this way, because the dummy DW is empty. This can also be worked around by reading the PageCount() from the DS and doing insertrow(0) on the dummy DW in a loop until its PageCount() value is equal.
All in all it works well and is indistinguishable from the regular printing behaviour.
There are no comments made yet.
- Page :
- 1
There are no replies made for this question yet.
However, you are not allowed to reply to this question.
However, you are not allowed to reply to this question.
I have done that for a while (2 months) now and it fixes ALL RANDOM CRASH happening.
And there are zero side effects.
I'm just so happy I cannot express. The random crashes constantly happened and we have been chasing our own code for moths. The "USER OBJECTS" in the windows task manager went from several hundreds to just 4 and now everything works perfect and maybe a bit faster.
*** THANK YOU Chris for this tip :-) ***
Everyone should know!!
//Steen