We have a lot of functionality on our library - and could adapt the global replace function to do this - but we would have to write a service that we would install in our ancestor class datawindow that could inspect all character string columns prior to an insert or update for escape characters and if present escape them.. A fair amount of work with the impact of retesting a huge system. Also string functions re not particularly fast - most windows based compilers inherit microsoft's routines which are famously slow - so one must consider the overall effect of adding this overhead to every transaction and the extensive retesting involved.
For the short term, I will need to address the use of rich text in few places, or extended multi line text fields that may have \.
One mitigating feature is that PB support says that we can dynamically change the disablebind behaviour during the unit of work and individually test. Much easier than string replacement. As it's very unlikely that the same connection will contend with itself in multiple transaction UOW's, this may be the most acceptable solution - but does require we assert defaults in the datawindow - or remove them from the update.
I would be OK with generally mapping the escape character to so obscure character - but not sure of the impact on the system.
No matter which we we go - looks like a fair amount of work to eliminate man holes...
What do you know about the size of the SQL buffer and how the use of bind variables affects the size of the transaction?
Also any tools for translating rich test to standard text?