Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (8)

Resolved Migration from 8 to 19 - data type errors

  1. Advice
0
Votes
Undo
  1. Kelly Amott
    Kelly Amott
  2. PowerBuilder
  3. Tuesday, 17 December 2019 22:15 PM UTC

New to PB 19.

Migrating an app from PB 8 to PB 19. I have a short list of errors. Two at least appear to be PB related and not coding issues - 

pfcmain.pbl(pfc_n_trp).2: Error C0001: Illegal data type: transport
pfemain.pbl(n_trp).2: Error C0001: Illegal data type: pfc_n_trp

Google found this - 

"It's ancestor (transport object )  is gone   declared as obsolete some versions ago.
Make sure also to delete n_trp in the pfe layer (pfe_main). "
(http://codeverge.com/sybase.powerbuilder.pfc/illegal-data-type-pfc_n_trp/836047)

Before I just start blasting at code can anyone provide guidance on working with obsolete code in PB? What else should I be looking for? 

---

These are the other errors which as mentioned I think are programmer issues.

export_datawindow.pbl(nvo_export_shared).nvo_export_shared.ue_export_report.36: Error C0081: Duplicate variable: li_y
export_datawindow.pbl(nvo_export_shared).nvo_export_shared.ue_export_report.191: Error C0116: Reference argument type does not match function definition: uf_calc_y
export_datawindow.pbl(nvo_export_shared).nvo_export_shared.ue_export_report.192: Error C0052: Bad argument list for function: ue_print_file_row

I think resolving the first error will resolve the others. In one instance li_y is delared as an integer and then as an array.

integer li_rc, li_cnt, li_total, li_d_row, li_y, li_success = -1, li_pos, li_grp
integer li_y[]

this.uf_calc_y( li_y, lds_data, lds_col, 'foreground', FALSE, FALSE, FALSE)
this.event ue_print_file_row ( lds_data, lds_col, 1, 'foreground', li_y)


Thanks.
  1. Error
  2. Migration
  3. PFC
  4. PowerBuilder (Appeon)
SQLCA connection
Is there a PowerBuilder DeCompiler available?
Responses (8)
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 19 December 2019 03:49 AM UTC
  2. PowerBuilder
  3. # 1

Hi Kelly;

 Miguel & Michael have given you some excellent tips. If however, previous PB developers have modified PFC_xxxxxx objects in the PFC_xxxxx.pbl's, then migration to a newer PFC version will be quite a monumental task. In the worst case, impossible and you might have to stay with your PB8 version of the PFC.

Regards ... Chris

Comment
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Wednesday, 18 December 2019 23:58 PM UTC
  2. PowerBuilder
  3. # 2

Hi Kelly

What I would do first, is make sure everything compiles well on PB8. Some of the error messages you're showing suggest it might not even compile correctly on PB8 (like the ones mentioning having to "declare an event before using it"): 

C0209: Function or event 'create' must be declared before it can be compiled.
C0209: Function or event 'destroy' must be declared before it can be compiled.
C0209: Function or event 'ue_retrieve_report' must be declared before it can be compiled.
C0209: Function or event 'ue_export_report' must be declared before it can be compiled.

This "sometimes happens" and can be resolved, but is a bit tricky. You'll have to manually edit the source code and add the event / function declaration headers to make these errors go away. Also, I remember that there was a time where "create" and "destroy" events would spontaneously appear as events in you event lists, although they're not supposed to. Again this can be fixed by directly editing the source code.

Don't forget to optimize all of your pbl's while / after fixing them.

Once the PB8 compilation works, personally I would first migrate to pb2019 using the old pfc's that you have:

With a little bit of luck, it's not that hard to get rid of any objects / data types which are no longer supported in pb2019. The "luck" would be not having used those no longer supported objects / data types too much.

Only then I would start thinking of migrating to "newer" pfc classes:

- Like said by Chris, you have to copy "only the pfC" classes. The "pfE..pbl" files might have overrides / overloads of pfC events / functions, that you don't want to loose. Since they might slightly differ from your old pfc classes, you'd have to use a comparison tool to make sure what's different and how it's different.

- If you're really unlucky, someone might have also modified some things within the pfC.. classes, although "your'e not supposed to do so". Still something you might want to make sure has not happened. Again, but comparing a "clean" pfc version of the same old version with what you've got.

In short: if you need any help and I think you do... You can contact me on mjlReina38 at hotmail dot com. I don't have oceans of time during working days (Europe), but with a little bit of luck things aren't that difficult to solve and I don't mind throwing in some time during the weekend. You'll probably won't want to give someone all of your code, so we can also think of an online session and resolving things on your PC. If that's not possible, then I'd definitely recommend you to take the advice of Armeen to get some help of any of the Appeon partners though I'm not sure how unexpensive they'd be.

regards

Comment
Load more comments
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 26 December 2019 20:40 PM UTC
I'm very happy you solved it! Great job.

Yes PB 2019 might have some issues. Also remember that from PB 10 on, PB is Unicode. So maybe it's a good idea to one day convert external API function calls to be Unicode, but should not really be an issue for now.
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 26 December 2019 21:41 PM UTC
Please paste this code in the PFC pfeappsrv.pbl, n_cst_platform_manager object. Constructor event:

//Protected:

//string is_separator

//string is_ClassName[] = {"FNWND3125", "FNWNS3125"} // this is for pb 12.5



// get the version of POWERBUILDER:

n_osversion ln_osver

string ls_PBVMName, ls_PBJavaDLL

ls_PBVMName = ln_osver.of_PBVMName()

if lower(ls_PBVMName)= "pbvm190.dll" then

is_ClassName[1] = "FNWND3190" // pb2019

is_ClassName[2] = "FNWNS3190" // pb20179

is_ClassName[3] = "AfxMDIFrame100su" // pb2019 for "dockable MDI"

elseif lower(ls_PBVMName) = "pbvm170.dll" then

is_ClassName[1] = "FNWND3170" // pb2017

is_ClassName[2] = "FNWNS3170" // pb2017

is_ClassName[3] = "AfxMDIFrame100su" // pb2017 for "dockable MDI"

else // pb12.6:

is_ClassName[1] = "FNWND3126" // pb 12.6

is_ClassName[2] = "FNWNS3126" // pb 12.6

end if





I'm not completely sure about:

is_ClassName[3] = "AfxMDIFrame100su" // pb2019 for "dockable MDI"

if wrong, I'll post you back once I can check it out. (on a holiday now).
  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Thursday, 26 December 2019 21:54 PM UTC
Sorry a small correction: that's not "n_cst_platform_manager" but "n_cst_platform" instead.
  1. Helpful
There are no comments made yet.
Kelly Amott
Kelly Amott Accepted Answer Pending Moderation
  1. Wednesday, 18 December 2019 22:45 PM UTC
  2. PowerBuilder
  3. # 3

Thanks Chris. Not my intention to have you debug my application so I'll try to keep things brief. I got the 2017 PFC library download and copied over all the PBLs. As mentioned previously I don't know if it's because the PBLs were replaced or if I've just gotten past that bump and am now dealing with new issues but I am getting all kinds of compile errors - 

These four account for 340 warnings - 

C0209: Function or event 'create' must be declared before it can be compiled.
C0209: Function or event 'destroy' must be declared before it can be compiled.
C0209: Function or event 'ue_retrieve_report' must be declared before it can be compiled.
C0209: Function or event 'ue_export_report' must be declared before it can be compiled.

In the errors I'm seeing things like this with some that seem system specific - 

C0015: Undefined variable: inv_datasecurity
C0051: Unknown function name: of_setbuilddate
C0015: Undefined variable: idw_export
C0051: Unknown function name: ue_retrieve_report
C0051: Unknown function name: of_getdatabase
C0051: Unknown function name: of_sv_readonly

 

I appreciate the help. 

 

Comment
There are no comments made yet.
Kelly Amott
Kelly Amott Accepted Answer Pending Moderation
  1. Wednesday, 18 December 2019 21:07 PM UTC
  2. PowerBuilder
  3. # 4

Thanks Chris. After searching Google and reading till I was cross-eyed I figured that might be it. It appears though that it isn't a simple matter of copying one PBL to replace another. I had gotten my build down to just the two data type errors and after replacing the PFC PBLs my compile exploded with undefined functions and undefined variables. I don't know if that's an adverse reaction or if it was just moving another step forward.

In earlier versions there are PBL and PBR files but in the GitHub PFC library for 2017 it's just a PBG. Can you provide guidance on how to properly update the libraries? I feel like I am THAT close.

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 18 December 2019 21:31 PM UTC
FYI: https://github.com/OpenSourcePFCLibraries/2017

=> download the first *zip* file from the Releases tab.

Note: You would only replace the PFC libraries.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 18 December 2019 18:33 PM UTC
  2. PowerBuilder
  3. # 5

Hi Kelly;

  FWIW: You would be best to replace the PB 8 PFC layer with one that matches the current PB versions.

FYI: https://github.com/OpenSourcePFCLibraries

HTH

Regards ... Chris

Comment
There are no comments made yet.
Kelly Amott
Kelly Amott Accepted Answer Pending Moderation
  1. Wednesday, 18 December 2019 15:03 PM UTC
  2. PowerBuilder
  3. # 6

Thanks so much for the guidance Michael! This will be an adventure. 

Comment
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Wednesday, 18 December 2019 17:32 PM UTC
Hi Kelly, We also have consulting partners that basically all day long are doing such migrations from really old versions of PB. If you have more issues than just this or get stuck, you may want to engage the help of one of them. https://www.appeon.com/consultants/consulting-partners
  1. Helpful
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Tuesday, 17 December 2019 22:55 PM UTC
  2. PowerBuilder
  3. # 7

Re: TRANSPORT object

It was part of Distributed PowerBuilder - peer-to-peer app interop across PB apps. Way cool back in the 1990s when invented. Too dangerous since no security. These days you would do web services, winsockets, or custom URL protocol handlers to perform such communication.

/Michael

Comment
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Tuesday, 17 December 2019 22:50 PM UTC
  2. PowerBuilder
  3. # 8

PowerBuilder IDE > Main menu > File > New > Tab = Tool > Migration Assistant

That is a very neat tool to look for potential issues across PB versions. Its user interface is a wizard. On page one choose middle option (syntax changes) - choose all the version since your PB 8 app may contain code that was obsolete albeit still working back then.

Remember, always copy your old PBL + PBT + PBW then analyze/migrate this copy.

Couple of extra gotchas since PB8:

  • PB10 onwards uses Unicode UTF-16LE internally. Prior versions used ANSI (or DBCS in non-US versions). This risks impacting especially calls to external functions like Win APIs.
  • PFC has changed alongside PB. New classes added. Extensions to gone classes (like Transport) removed.
  • Your embedded SQL dialect may be outdated compared to your DB server. PB migration assistant does not consider SQL dialect changes.
  • PB compiler gradually became stricter. You may see duplicate variable declaration that turn into error in new PB versions.
  • Also, you may discover some runtime errors when typecasting if the typecast is invalid but old version let your app do it anyway. That usually resulted in hard crashes. These days you get runtime error telling you want is actually wrong.

All in all I would expect most code to just work absolutely fine despite some odd bits and pieces.

Good luck! /Michael

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.