Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Convert version 3.0 to version 7.0

Status
Not open for further replies.

Matth007

Programmer
Mar 21, 2001
1
0
0
BE
Hello,
I'm programmer in Cap Gemini Luxembourg, and a customer want to move his program from powerbuilder 3.0 to PWB 7.0.
I have no competence in this language, but if it is possible to do so, I can find competences.
So, my question is: Is there many imcompatibilty problems to convert a powerbuilder program programmed in version 3.0 to the version 7.0?
Please... answer me quickly... the customer is still waiting...

Thanks in advance

PS: excuse my english but I begin in this language...
 
Fundamentally, yes. It is possible to convert it but it is not straightforward. The real question is why the customer wants to do the migration to version 7.0. If it is to move to an n-tier model with e.g. Jaguar then this will add a layer of complexity to the problem. If it is to move to a fully OO paradigm, that will also add complexity and rework to the process.

If it is just a straight move across to 7.0 then this should be relatively quick and painless but you will get none of the benefits of using 7 and will end up doing more rework in the longer term.
 
stevecal mentions some good points. Version 7 together with Jaguar can take advantage of n-tier architecture and offers the possibility to logically and physically partition your application (client/app-server/database-server). Frankly, I think there will be a world of hurt involved in migrating from version 3 to version 7. Version 3 hasn't been supported by Sybase for nearly 5 years. Inevitably there will be portions of Powerscript in version 3 that are no longer supported in version 7. These scripts will have to be substituted for new ones. If the customer's plan is to use PB 7 as a standard for moving forward with much of their application development, then migrating the old application to version 7 is a logical move. If their policy is not to use it as a development standard, for new applications as well - then it may be cheaper to simply rewrite the old application.

Finally what you may want to explore is using a PB code analyzer. Tools such as these will scan your code and check it for various standards.

Check out this site: They have such a tool - but even this one only works from version 4 and higher. I'm sure that there are other 3rd party code analyzers around as well.

Have fun!
 
OperaMan

The trick with doing a like-for-like migration of this order of magnitude of version difference is automation. The way I would do this would be to export all of the code to ascii, grep through for non-standard syntax, isolate those blocks, convert it to v7 syntax, put v7 headers on and then reimport. There will be a few issues but not enough to lose sight of the goalposts. The only big nasty is if there are blocks of code which are too big to reimport: I did a migration of v4 PB script to 6.5 a few years ago (written originally by one of the big 4 consultancies) which was complete **** and contained one proc on a button of about 14,000 lines of code....
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top