• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Mismatch Table columnname datatype Text and PBuilder datastore columnname char(4099)

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

Resolved Mismatch Table columnname datatype Text and PBuilder datastore columnname char(4099)

  1. Issue
0
Votes
Undo
  1. Anton van der Post
    Anton van der Post
  2. PowerBuilder
  3. Tuesday, 27 February 2018 19:59 PM UTC

 

Application was migrated to PB2017 R2 from PBuilder 9
DataBase Table defintion columnname "notes"   datatype Text
PBuilder9 Datastore/Datawindow columnname "notes" datatype Char(4099).
PBuilder 9 display the "notes" value.

PBuilder 2017 R2 does not display the "notes" value.

Found two ways to fix this:
- change datasource the datasource is changed
  e.g. convert( char(4099), orders.notes ) as notes

- to prevent loosing the Update Specifications of the Datastore
  Edit source of the datastore/datawindow
  and replace char(4099) with char(32766)


Is there a faster way to do this - we have around 50 - 70 different datastores/datawindows
to fix.


Thank you,

Anton

 

 

  1. Migration
SAP - Powerbuilder Licensing
PB 12.6 Appcrash
Responses (4)
Frode Guldberg
Frode Guldberg Accepted Answer Pending Moderation
  1. Friday, 2 March 2018 08:57 AM UTC
  2. PowerBuilder
  3. # 1

Hi

We have encountered the same problem and it seems to be related to the database driver. If we connect via OLEDB it works fine, but if we connect using SQL Native Client we don't get any data in the column being 4099 characters wide. We found that increasing the width of the column in the dw syntax to 9999 makes it work, but when changing it you should of course go for the full length.

 

Frode

Comment
There are no comments made yet.
Kim Berghall
Kim Berghall Accepted Answer Pending Moderation
  1. Wednesday, 28 February 2018 20:55 PM UTC
  2. PowerBuilder
  3. # 2

You have to fix them all. Also perhpas consider changing from datatype text to some reasonable varchar column. Could even change them to varchar(4099) then it might work without chnaging the dws. The good thing is that PB actually recognizes the correct datatypes now. It still can't handle bit correctly... so we have to cast it as tinyint.

Comment
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 27 February 2018 21:24 PM UTC
  2. PowerBuilder
  3. # 3

Hi Anton;

   Yes ... your coming from an ANSI version of PB (v9.x) whereas, PB 10.x and higher versions are Unicode based - a.k.a. Double-Byte in nature. So when your DBMS VarChar data - if stored in UTF-8 (single byte) format for example - is sent to a PB control, its internally converted to UTF-16LE (which is the current MS-Windows encoding standard).

   So changing your columns length is required to accommodate the new double-byte data length. You would have encountered this situation beforehand if migrating to any intermediate release of PB before v2017.

HTH

Regards ... Chris

 

Comment
Anton van der Post
  1. Anton van der Post
  2. Wednesday, 28 February 2018 13:48 PM UTC
Thanks Chris



- I'll continue with the replace of char(4099) to char(32766) to be unicode compliant.



Regards



Anton

  1. Helpful
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Tuesday, 27 February 2018 20:51 PM UTC
  2. PowerBuilder
  3. # 4

Hi Anton,

Does SQLCA.DBParm += ",StaticBind=0" improve the app behaviour?

As I remember disabling "static bind" forces the DataWindow engine to perform a describe on the SELECT statement prior to retrieving data.

This can also fix issues like "truncated string" when DB columns are extended after your DataWindow was created.

It will therefore have some impact on performance.

 

HTH /Michael

Comment
Anton van der Post
  1. Anton van der Post
  2. Wednesday, 28 February 2018 14:01 PM UTC
Hi Michael, I have decided to go the "hard" way - replacing in each datastore / datawindow char(4099) with char(32766) - to make the application Unicode compliant. And yes - I encountered a string truncation issue - which was easily solved by changing the underlying stored procedure. Thank you for your quick response, Anton

  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.