Hi William;

  Going from an ANSI (single byte) to a Unicode (double-byte) version of PB, the O/S and SS for that matter, can certainly make a difference. SS for example goes from UTF-8 to UTF-16LE encoding along with PB and the O/S. These changes just in themselves while adding more flexibility in handling the extended character sets, do add more processing overhead.

  I assume when you mention "Word" that you are talking about MS-Word. That is another aspect as well - MS-Office, as newer versions like Office365 add more over-head as well due to various factors like new features and 64 vs 32 bit operation. Even PowerBuilder 2019 Rx now can compile into 64 bit application EXE's that add more memory accessibility, yet can take a longer time to start due to the way the O/S handles the larger address space / memory allocating.

  In order to help you further though, we would need a lot more details on your environment, application structure, code snippets, compile settings, etc in order to provide more meaningful feedback.

Regards ... Chris

Hi,

How slow is slow?

A lot of people have complained about the newer versions of Powerbuilder being slower (and they are), but many of the problems have been fixed by distributing a PB.INI file with the executable. (and for the IDE, editing the pb.ini used in powerbuilder too).

This is the contents of my pb.ini (only the bold text is relevant):

[PB]
UseSimpleMAPI=No

[DataStore Behavior]
UseHwnd=No

[Data Window]
ACCESSIBILITY=0
ForgetColumnKeyboardLayout=Yes

[RichText]
PageSizeAsControlSize=1

We are using Office 365 and Word opens "reasonably" fast, like around one second.

I'm not saying this will solve your problem, it might also have something to do with, for example, the settings of Word's "Trustcenter", where you can speed things up by allowing files to be trusted when on a network, etc. Also look if you don't have some addon which might be slowing down opening a document.

regards

PB2019R3 build 2703
Windows 10, 64 bit platform
Oracle 12.2, 32 bit client


After >>> MUCH <<< research, I found that when the DBPARM in SQLCA was set with "DisableBind=1", processing was at least 5 times slower that when the DisableBind was set to zero or just left off the transaction object.

However, when we set DisableBind=0, we started getting "All variables not bound" errors all over the place.

Our solution was to have DisableBind=1 for all visual processes, but for non-visual processing in the one main are where we really need the speed, we temporarily set it  to zero, then return the setting to 1 when we are done.