1. Don Moore
  2. PowerBuilder
  3. Thursday, 27 February 2020 19:03 PM UTC

We have many PowerBuilder 2017 Release 2 applications that will need to be migrated to Release 3, as their attendant Oracle Server databases will be transitioning to 19c (12.2.0.3) in the future. Appeon PowerBuilder 2017 Release 3 is stated to support Oracle 18c/19c.

 

1) Is it correct to assume that the IDE for PowerBuilder 2017 Release 3 installs “on top of” Release 2; in other words, a single computer can have one or the other but not both? (2017 Release 2 installed separately from 12.6, and one could have both during a development transition period.)

 

2) Do you know if already built Release 2 PBD’s and EXE application files will execute correctly if the xxx170.DLL files are replaced with the Release 3 DLLs, or do the PBD’s and EXE have to be migrated and re-built to function correctly with the revised 170.DLLs?

 

2b) If the xxx170.DLL files can be simply be replaced without migration, rebuild, redistribution, will the applications then be able to use the Oracle 12c (12.2.0.1), 18c (12.2.0.2) and/or 19c (12.2.03) Clients? (2017 Release 2 does not work these Oracle 32-bit Clients.)

 

Thanks in Advance

 

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 27 February 2020 19:54 PM UTC
  2. PowerBuilder
  3. # 1

Hi Don;

1) YES. However, after that installation - please install MR #2170 to be O18C/19C compliant.

2) Since PowerSoft's PB version 1.0 - always do a Full Build and then recompile after any update so that the generated code in the EXE and PBD's match your new run-time DLL's (PBVM). Otherwise, unpredictable behaviour may occur.

3) PB2017R3 build 2170 will work with either O18C or O19C DB Client drivers in 32bit or 64bit mode. Note that the IDE and PowerServer ToolKit require the 32bit drivers but your 64bit PB App EXE's and PowerServer will require the 64bit Oracle DB Client drivers.

HTH

Regards ... Chris

Comment
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Friday, 28 February 2020 00:48 AM UTC
  2. PowerBuilder
  3. # 2

Re 1) Across releases the filename remains identical while internal version number changes. PB IDE defaults to install into same folders across releases of same version. So files overwrite prior versions. Example:

  • File = PBDWE170.DLL is DataWindow Engine's main runtime file
  • In my current install it has version number = 17.2.0.1915 where
    • 17.0 = PB 2017 GA
    • 17.1 = PB 2017 R2
    • 17.2 = PB 2017 R3
    • 1915 = Build number
  • In my install I also have file = PBDWE190.DLL with version number = 19.1.0.2279.
    That version + build is customer beta of PB 2019 R2.
  • PB docs state we can expect same number scheme to continue at least through PB 2019 and its releases

Re 2) Never run a PB app on a different runtime version than it was compiled for!

  • That is true for new releases that change runtime's feature set.
  • That is also true for new patches/EBFs since a bug fix or security fix could mean compiler change. Hence, that fix only applies after a recompile.

Reason for this restriction even for bug fixes => Any bug fix may be a fix to the compiler or both compiler + runtime. Such fix is only "live" after new app deployment.

I remember teaching that rule from PB3 onwards. Make it a habit to be on the safe side.

HTH /Michael

 

Comment
There are no comments made yet.
Don Moore Accepted Answer Pending Moderation
  1. Friday, 28 February 2020 15:02 PM UTC
  2. PowerBuilder
  3. # 3

Thank you Chris and Michael.

Your replies were exactly the information (confirmation) I was looking for. After 48 years in software development (in an extremely wide variety of languages and environments), I do know that there are usually no shortcuts, but it was worth a try. Thanks again, especially for the rapid response! We're looking at migrating 9 or so PB applications (along with some Apex applications, Crystal Server interfaces, secure file exchange server interfaces) spread across 3 Oracle servers with 500 - 1000 users, ”in house” and through Citrix, and I can now inform management of the extent of the work and timing involved to accomplish this task. I will grab another computer, consume another Appeon license and keep my Release 2 and Release 3 development environments separate. As for the actual migration, I expect that it will be straight forward, simple, fast and issue free, just as it was going from v12.6 to 2017. LOL, I may end up retiring on this one (as it is just me)!

Comment
  1. Armeen Mazda @Appeon
  2. Friday, 28 February 2020 17:13 PM UTC
R3 is revision of 2017 major version and it is a long-term support version. I would be extremely surprised that going from R2 to R3 is not a piece of cake.
  1. Helpful
There are no comments made yet.
Bill Asby Accepted Answer Pending Moderation
  1. Friday, 28 February 2020 17:43 PM UTC
  2. PowerBuilder
  3. # 4

Great question Don Moore.

My organization is going to be doing the same thing.

This is helpful.

Thanks,

Bill

 

Comment
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.