Thanks Breck
What is documented in SQL Anywhere is the behavior of literal strings, what is documented in Powerbuilder is the effect of disable bind on defaults.
Nowhere does it say that if if you are using a data control (e.g datawindow) with disableBind=1, that your character text columns will be corrupted if the database sees character sequences that look like escapes. This is the Open Manhole...
So while those that hand code their SQL statements and use literal strings to do so may have had more of a heads up on this, those that rely on data controls which obscure the syntax created may have had this happen without being immediately aware.
We've already been doing research on changing the disable bind in our applications and we confirmed the issue where our database defaults now fail to function despite the column being supplied with Null values. That means every transaction that was relying on default database behavior has to have its defaults coded. A serious amount of work in many hundreds of transactions.
There may also be situations where we either have to tolerate user entered text data being corrupted or the the application failing because of the size of the SQL statement generated. This may have been the reason we changed the disablebind in the first place and I'll have to do some historical research to see if this remains an issue.. Certainly scanning every text field and escaping the escape on the insert and update is not an option.
Personally, I was surprised that this issue has been known to SA development for so long without responding with a way to mitigate it by allowing it to be turned off or the \ escape mapped to a different character. Your comment on this, which I quoted above, goes back some years. It looks as if there is a feature to change the escape character and I have asked support for more information on it (the documentation warns against it).
Lately, as a SA partner, our annual partner support fees and customer license fees have skyrocketed, and the licensing processes ever more byzantine. We noticed Microsoft SQL Server apparently does not have these interface issues and it is definitely fueling some re-evaluation of our technology choices.
Thanks again, I have always appreciated having you here in the forum. I just wish the company itself took as much interest as you do.