I have been tracking down the issue of corruption of our Rich text in our PB 12.6 app and discovered via communications with PowerBuilder and SQL Anywhere Support that if you set DisableBind=1 in your connection, that SQL Anywhere will look for character string sequences inside varchar columns and translate them to special characters when storing them in the database.
So for example a \n anywhere in the string sent to the database via a datawindow column will be converted to a newline in the database. If you didn't want this to happen then you need to find and replace \n's with \\n's which is will translate to \n as stored.
We had seen this previously in our data occasionally, but assumed it was a data entry error, however it shows up most obviously with Rich Text stored in long varchars, because in PB 12.6 the Rich text Control sequences include some formatting instructions which have a \no... string in it - and the \n is replaced on the way to the database. When you re- retrieve the data you will see the characters owidctlpar preceding your text. This is a corruption of \nowidctlpar.
I have yet to discover what other character sequences can be corrupted - but its safe to say that you cannot trust the integrity of any varchar column inserted into the SQL Anywhere database (6 through 16) if your connection includes DisableBind=1.
Your options are pre parse the strings and replace the \n with \\n , Set DisableBind=0, or use a Blob.
I know we needed to DisableBind Variables as some point in our development history. SOme of it may have had to do with the size of some of our SQL Queries. There is some light mention of this in relationship to the datawindow in PowerBuilder, is there any robust documentation on the impact of Bind Variables on how a datawindow interacts with the database?