Hi Pradeep,

No need for intermediate version when migrating PB 5 to newest version. What I would expect as issues when migrating PB5 code:

• Unicode - as pointed out by Roland
• Stronger compiler checks - C0174 is one such case.
  • For each version the compiler increased its checks
• New system defined events, event ID's, and event signatures - EX
  • To support win64/win32, recent PB versions have "longptr" datatype in PBM_CustomXX events, PostEvent(*), TriggerEvent(*), and perhaps a few other places
• New system classes, controls, and syntax - EX
  • PB 5 is first version with DataStore  and .object notation for DataWindows.
  • Exceptions and TRY-CATCH was introduced in PB 9.
  • PB 5 also introduced custom events with event ID and return-codes from ItemChanged/ItemError.
  • TreeView, ListView, TabControl, and several others
• PB 5 containing pre-PB 5 coding patterns. EX:
  • ​SetActionCode(...) instead of "return ..."
  • Custom events using PBM_CustomXX despite no intention of having the event called from external apps
  • A hidden window containing DataWindows - which is the pre-PB 5 method of writing DataStores
  • Very shallow inheritance hierarchies because inheritance had been slow in early PB versions
  • VBX control to provide tab controls, tree views, etc. - since PB 5 is first version to implement such controls as PB system controls
• Obsoleted functionality
  • Biggest impact is "Distributed PowerBuilder" which was excellent peer-to-peer communication
• Performance considerations -
  • PB 11 (or close to PB 11) the .object notation got fast - a lot faster.
  • Code that was best performing in PB5 may now actually be worse performing.
• Use of external components
  • You may have difficulty using an outdated VBX/OCX control.
• Database version compatibility - since you most likely also have to deal with DB drivers being upgraded
  • You may have PB5 app run use an old DB driver that requires updating as well to be supported in current PB.
  • You may also have SQL in DW objects or as embedded SQL that need to change because of DB version

It really is a case-by-case scenario how much rewrite and/or fine tuning is required when you migrate existing code. As Roland points out the Migration Assistant is a good utility to estimate the effort.

Good luck,   /Michael

You shouldn't need to migrate to an intermediate version. In versions 8 and higher there is a Migration Assistant which you can get to by clicking New and then going to the Tool tab. It will analyze your application and point out things that should be changed.

A major change was in version 10 when Unicode was introduced. String and Char variables are now 2 byte Unicode instead of 1 byte Ansi.