1. J Vier
  2. PowerBuilder
  3. Wednesday, 08 August 2018

I'm maintaining a legacy client-server ERP application developed using PB8. I'm trying to migrate it to PB2017 due to deprecated DB-Library connection to SQL Server not available in Windows 10 clients.

Migration Assistant in PB2017 revealed 40 issues in PowerScript used. Mostly reserved syntax change required with "try", "catch" and "throws". These I could fix. Actually I found out that even the Migration Assistant in the old PB8 lists these, so the app is not even a clean PB8 level app. Never noticed before.

Because of the number of syntax changes required, I went on migrating the app in PB2017, just to see what happens. The process got completed with 1500 errors. This is too much to cope with one by one, of course. Anyway, I'm curious to understand what's going on with these.

First just a few distinct error messages that seem to be very common in my case:

Error C0042: Cannot compile without valid database sign-on.
Error C0103: Dynamic SQL command must reference DynamicStagingArea object.
Error C0019: Incompatible property sqlcode for type powerobject
Error C0003: Condition for if statement must be a boolean.
Error C0039: Cursor/Procedure (gc_cursor) has not been declared.
Error C0031: Syntax error
Error C0015: Undefined variable: gs_servername

Here's a few I'd like to hear your comments especially:

(f_fileopen).7: Error C0051: Unknown function name: shellexecute16
(f_fileopen).9: Error C0051: Unknown function name: shellexecute32
(f_fileopen).13: Error C0015: Undefined variable: gl_errorcode
(f_fileopen).14: Error C0015: Undefined variable: nok
(f_fileopen).16: Error C0015: Undefined variable: ok
(f_fileopen).18: Error C0094: Routine must return a value.

The source code of the global function f_fileopen:

global type f_fileopen from function_object
end type

forward prototypes
global function integer f_fileopen (string as_file)
end prototypes

global function integer f_fileopen (string as_file);long ll_temp
environment lo_env

GetEnvironment (lo_env)

IF lo_env.Win16 THEN
ll_temp = ShellExecute16 (Handle (w_mdi_main), "open", as_file, "", "", 1)
ELSE
ll_temp = ShellExecute32 (Handle (w_mdi_main), "open", as_file, "", "", 1)
END IF

IF ll_temp <= 32 THEN
gl_errorcode=ll_temp
RETURN NOK
ELSE
RETURN OK
END IF
end function

The two shellexecute external functions are declared.

The three undefined variables are declared as global constant variables.

In PB8 the actions Full build and Deploy work just fine for the application.

Basically my question is: Is it worth fixing those 40 syntax issues revealed by Migration Assistant? May I expect fixing to help considerably with the 1500 errors given in the migration phase?

I would appreciate your advice!

Accepted Answer
Bradley Schultz Accepted Answer Pending Moderation
1
Votes
Undo

You first need to make sure that you can connect to the database to resolve the Error C0042: Cannot compile without valid database sign-on. Create a dbconnection profile in the database painter to connection to a test database. Once this is resolved, the number of errors should go down significantly. Until you can resolve these you won't be able to tell real issues from db validation errors.

 

b  r  a  d

Comment
Thank you Bradley! I failed to see that the db connection is so critical during migration, as I wasn't yet trying to run the app. Creating a dbconnection profile helped for sure: The migration finished succesfully. No more errors, just two warnings (related to 'help' event overloading).

Quite a bit better starting point for testing...
  1. J Vier
  2. Wednesday, 8 August 2018
There are no comments made yet.
  1. Wednesday, 8 August 2018
  2. PowerBuilder
  3. # Permalink
Chris Pollach Accepted Answer Pending Moderation
0
Votes
Undo

Hi Kim;

  The MSS DB Interface hos not been supported in many PB releases. MSS was replaced by the SNC db client.

ie:  SQLCA.DBMS = "SNC"

HTH

Regards ... Chris

Comment
There are no comments made yet.
  1. Tuesday, 14 August 2018
  2. PowerBuilder
  3. # 1
Kim Berghall Accepted Answer Pending Moderation
0
Votes
Undo

I am thinking the old db connection should still work on Windows 10 too. We have a PB 9 app and it works fine with MS SQL Server on all versions of Windows. However, we have now upgraded to PB 2017 with MS SQL Server Native Client, which works really well.

Comment
This is interesting! In my case in Windows 10 client the Powerbuilder app shows a database error "DBMS MSS is not supported in your current installation.". In Windows 7 the same application connects to the database without a problem. SQL Server client is not installed in either of those clients. All the dll's are located in the same folder as the Powerbuilder app .exe file. Any idea how I could get the old DB-Library based connection to work in Windows 10?
  1. J Vier
  2. Monday, 13 August 2018
I am not sure, you need the ntwdwlib.dll, dbnetlib.dll and pbmss80.dll files. I assume PB 8 would work, at least PB9 works.
  1. Kim Berghall
  2. Monday, 13 August 2018
There are no comments made yet.
  1. Friday, 10 August 2018
  2. PowerBuilder
  3. # 2
Michael Kramer Accepted Answer Pending Moderation
0
Votes
Undo

Hi Jouni,

PB 8 runtime uses ANSI characters/strings having no Unicode support.
PB 2017 runtime uses Unicode with options to integrate with ANSI based code.

However, you must be careful where text is:

  • Converted to/from bytes or BLOBs
  • Read from or written to files
  • Exchanged with external code (like calling external functions)
  • Exchanged with database where driver may require certain text encoding

A few specific pointers:

  • Text files :: FileOpen and DataWindow.SaveAs default to EncodingANSI!
  • Using external functions :: You must be explicit if external function is ANSI based
    • EX: ... LIBRARY "..." ALIAS FOR "...;ANSI"
  • Whenver first 3 characters min a string look weird => This is the BOM (Byte-Order Marker).
    • See PB help file for FileOpen for details
  • Environment structure in your code sample:
    • *.Win16 is obsolete!
    • *.ProcessBitness is integer. Value = 32 or 64

Enjoy,

/Michael

 

Comment
ProcessBitness tells you if the app is compiled to 32bit or 64bit. You are correct, Win16 is obsolete. It is no longer necessary to know the bitness of Windows.
  1. Roland Smith
  2. Monday, 13 August 2018
There are no comments made yet.
  1. Friday, 10 August 2018
  2. PowerBuilder
  3. # 3
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.