1. Glenn Barber
  2. PowerBuilder
  3. Wednesday, 21 March 2018 20:27 PM UTC

We have a pfc based Powerbuilder 12.6 app  using SQL Anywhere that we are starting its migration to PB 2017.

We handle international film distribution and some of our customers want to be able to enter the local European language names - but our current app has varchar columns and the entry does not support saving names that are in language characters not in the us asci.

We tried to accommodate this with nvarchar database types - but I believe we ran into issues with the SQL Anywhere odbc interface and use of bind variables.

I am sure others around the world must support the extended language character sets and use SQL anywhere.

Can anyone tell us what works for them?



Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 21 March 2018 20:52 PM UTC
  2. PowerBuilder
  3. # 1

Hi Glenn;

     Have a look at the new column data types NChar & NVarChar in order to handle the extended character sets. Also, when you create your SA DB - you can now  specify Unicode format vs ANSI (default).  FYI: Have a look at the Unicode demo DB's that come with PowerBuilder and InfoMaker ( PB Demo DB V2017R2 Unicode  and PB Demo DB V2017R2 IM Unicode respectively )


Regards ... Chris

  1. Glenn Barber
  2. Sunday, 1 April 2018 00:04 AM UTC
Sorry I missed your response - no notifications from this forum.

I believe in my earlier email I did mention trying to use nvarchar - however if you disable bind variables the characters corrupt the SA ODBC interface and we loose other important features we would like to have with the database interface - including defaults etc.

The Unicode SA creation is interesting - do you know if there is a way to upgrade an ANSI database to Unicode?

Have you any experience using Unicode in SA with the Bind Variables disabled?




  1. Helpful
  1. Glenn Barber
  2. Wednesday, 11 April 2018 17:49 PM UTC
HI Chris

For some reason replies don't always get posted - so I'll ask this one again.

Our problem had its roots in the ODBC interface, if we didnt use bind variables (for several good reasons), the special characters packed into a string were breaking the interface and producing illogical results.  If we change the database so that it is using Unicode, is there something we need to do in the ODBC interface so that It knows how to deal with the unicode strings?

Secondly, Is there some utility that can upgrade a database from ASCI to unicode?



  1. Helpful
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.