I’m beginning to think that just truncating the string to something well short of the column limit is going to be the simplest way to go. This has been a persistent issue in the past with earlier versions of this app that were handled by the previous programmer/dba by…manually editing the file to fit by trial and error.
It happens with just a few records every time (this is a once-a-year process) and it’s always like this: the input is too long by a relative handful of bytes. (The actual data is supposed to be *short* comments in a review process, and some of the reviewers are really wordy. All I ever get is a csv of the responses, so I’m limited in my options. I could move to a BLOB but this is a lot of work to manage a few responses in this system. We retain the original data always so if anyone really wants the whole novella-length ’short comment’ for review we can get it. :-) Thanks for the deep dive into the complications I'm facing! A lot of food for thought. On May 27, 2021, at 5:09 PM, Fennell, Brian <fenne...@radial.com<mailto:fenne...@radial.com>> wrote: There are also "lossless" ways of encoding "illegal characters", such as UTF-8 encode first then Mime Q-Encode (quoted printable) or using XML / XHTML entities like this - | or UTF-8 encode then percent-encode. This can be used work around special characters when you are dealing with mostly English with some European characters and an encoding that is either 7-bit-ascii compatible or can easily be converted to and from (losslessly) 7-bit-ascii (such as EBCIDIC with some creativity). And there is always good old hexadecimal. It all depends on your use-cases, how much control you have over your environment and how much time you can spend being clever. -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs
