1. Gordon Leishman
  2. PowerBuilder
  3. Friday, 10 May 2019 04:02 AM UTC

Hi all,

Just looking for any advice on potentially moving our deployments from 32 bit machine code to 64 bit pcode.

Are there any benefits in going to 64 bit and does anyone know of any issues or pitfalls that might arise from moving to 64 bit or pcode?

I would assume a full regression test of the application would be recommended?

Our app is a PB 2017 desktop app using SQL Server 2012 DB connecting through ODBC. The user environment is Windows 10.

Any advice would be appreciated.

Thanks
Gordon

Gordon Leishman Accepted Answer Pending Moderation
  1. Monday, 13 May 2019 01:14 AM UTC
  2. PowerBuilder
  3. # 1

Thanks for the responses guys, some great points.

The reason I am looking at 64 bit is that it seems to improve performance of some data windows in our application that retrieve large amounts of data.  With these data windows we see some memory leakage and application hanging in 32 bit that we don't see when we build in 64 bit.

PB 2019 also appears to fix the issue (it think it is Bug 544).

So we are just trying to make a decision on whether to go 64 bit now or wait 6-12 months and upgrade to 2019, as the powers that be aren't keen to upgrade to 2019 until it has been in production for a period of time.  

 

 

Comment
There are no comments made yet.
Marco Meoni Accepted Answer Pending Moderation
  1. Friday, 10 May 2019 06:12 AM UTC
  2. PowerBuilder
  3. # 2

Hello, Gordon, 

per se, it's not that important to have 64-bit applications. However, in short:

  • Benefits: access much more memory (for large datastore, structure arrays, etc) instead of being limited somewhere around 2GB (per application). In principle 64bit operations on 64bit O.S. are also 2x faster than 32bit O.S. where you need 2x32bit ops for the same task.
  • Stability: there should be no difference.
  • Caveats: you need 64 bit database drivers, ODBC DSNs, DLLs, PB runtime and dependencies. So, be ready to spend some time in packaging correctly your 64bit distribution. Definitely, also good practice to undergo full regression test.

Best,
.m

Comment
  1. Chris Pollach @Appeon
  2. Friday, 10 May 2019 14:20 PM UTC
Plus ... accessing the 64 bit side of the registry.

Useful when conversing with other 64 bit apps via their registry entyies.
  1. Helpful
  1. David Peace (Powersoft)
  2. Friday, 10 May 2019 14:36 PM UTC
The question I would ask is why do I need to be 64Bit, if the business wants to move to 64Bit office products etc then there is a case for doing so. If you install SQL Server 64Bit client it also installs the 32Bit client so that's covered.



My concern has always been that if you hit problems in the run time environment you cannot debug them in the IDE because that is still 32Bit. So any links to external DLLs, Applications etc will all have to be 64Bit and you will be developing in 32Bit.



At this point we have stuck with 32Bit to be safe. We had one client who only had 64Bit Office and wanted integration to that, but then installed Sage 50 account which was 32Bit too so we gave them the choice, we could talk to Sage 50 and not the 64Bit office or they could switch back to 32Bit office and we can integrate to all.



Hope that helps.

David
  1. Helpful
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.