1. Kwadwo Boahene
  2. PowerBuilder
  3. Friday, 31 January 2020 20:07 PM UTC

We  are thinking of migrating our PB Classic application (2017 build 1769) from DB2 v11 to Microsoft SQL Server 2016. Currently we connect to DB2 via ODBC. Any suggestions on what to do? Are they any tools that can help? Will native connection be better?

 

 

Thanks,

KB

Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Friday, 31 January 2020 20:29 PM UTC
  2. PowerBuilder
  3. # 1

Theoretically, native will offer better performance than ODBC.  But unless your app is extremely demanding you may not notice difference.

Another benefit of not using ODBC is you can take advantage of SQL Server-specific functionality.

Most customers use the native SQL Server client.  But Microsoft is no longer enhancing this.  So we are working on supporting SQLOLEDB driver.

In the interim, you can continue use ODBC, but eventually we recommend switching to the SQLOLEDB driver.

 

Comment
  1. Rexford MacGregor
  2. Friday, 14 February 2020 15:34 PM UTC
is SQLOLEDB the preferred way to connect to MS SQL from PB19 vs the native MS SQL client?

  1. Helpful
  1. Armeen Mazda @Appeon
  2. Friday, 14 February 2020 16:34 PM UTC
No, not in first release of PowerBuilder 2019. This is feature planed for PB 2019 R3. At that point, after you thoroughly test the new interface, yes we would recommend to switch to that since Microsoft is no longer enhancing the MS SQL native client.
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Friday, 31 January 2020 21:06 PM UTC
  2. PowerBuilder
  3. # 2

Hey, don't forget database error handling probably needs revision when you migrate from one DBMS + DB driver to another.

With ODBC you have two sets of error codes:

  • SQLDBCode - property of SQLCA (transaction class) which contains DBMS specific error codes
  • SQLSTATE - part of error message (property = SQLErrText) - standardized across ODBC drivers.

If your app processes SQLSTATE you may have less migration work for error handling when your aoo remains using ODBC since MSSQL in most cases produces same SQLSTATE values as DB2.

However, if your app like most apps I have seen processes SQLDBCode then you won't see such benefit from remaining on ODBC.

 

Comment
There are no comments made yet.
mike S Accepted Answer Pending Moderation
  1. Friday, 31 January 2020 21:37 PM UTC
  2. PowerBuilder
  3. # 3

look at microsoft for their db2 migration documentation.

you need to review any sql you have for db2 specific functions and/or outer join processing.  the more ansi standard everything is, the less you will have to change.

for example coalesce is the ansi standard so you are good if you used that with db2.  but maybe it has a different function to do the same thing? (for example oracle uses nvl, i have no idea what db2 may have used, isnull() is sql server's 'old coalesce')

 

 

 

 

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.