what happens when you put text into the column that is larger than 32K?  does the same problem occur?

If you do change the pbmaxtextsize value to 1GB, then the char size in the datawindow displays as char(999999). 

Perhaps the real problem is that you have entered more than 4099 in the column?  did it display when smaller text was entered?

Setting the field size limit to 4099 or 32K and sticking to it may be the real fix here.  If you need larger than that, use select/update blob syntax.

I suggest reporting these results to appeon.  At the least this should be in the documentation whether its a driver issue or a datawindow issue.   This may simply be how the driver works and developers have to work around it.  Appeon has been good at adding these tidbits to the documentation.

Have you tried setting staticbind in your database connection?

https://docs.appeon.com/pb2019/connection_reference/ch01s01.html#StaticBind

It will slow down the dw retreives, but it will allow you to use existing datawindows without changing the column size.  I have no idea whether that will fix your 4099 vs 32k issue for varchar(max).   That is just assuming that the problem really is the column size.  I never have problems with retrieving too large a value, but i do when sending updates/inserts/deletes.

also, if your varchar(max) is still larger than 32K then you may have to retrieve it down differently.  PBMaxTextSizedatabase parameter may come into play here depending on your database driver.  The default is 32K, but you can extend to 1GB.  only available for certain database drivers (MSOLEDBSQL & SNC)

Database parameters and supported database interfaces - - Connection Reference (appeon.com)

Hi;

  This could be related to a long time bug (glitch) that was identified in the PowerSoft days, re-identified in the Sybase days, etc but never fixed. This glitch is that the PB IDE never updates the DWO source during a migration. Thus when your running the migrated App in your case, the DWO's still think they are running as PB 9 not 2019.

   To see if this is affecting your App. Try editing the "source" of one of your problem DWO's. You'll pry see that the 1st line states "release 9;". If migration did its job properly, the 1st line should be "release 19;". Since you have the DWO source open, change the "9" to a "19", save the DWO & then run your App to see that fixes the issue. It should because newer DWO code ignores the String(NN) column length and always dynamically expands its primary buffer to 32K per column if needed. HTH

 PS: note that after changing the "release" number & saving the DWO, reopen the DWO source right afterwards. Notice how much more robust the source code is.  ;-)

Regards ... Chris

I would export all the DW SRD files and then using VI to find and replace the CHAR(4099) to CHAR(32000).

If you don't have acces to VI it would be quite easy to write a PB program to read the SRDs and change the syntax.