Thank you for your input. I decided to do away with the "old" method and go with the parametirzed expression. You are right; it is simpler and fewer problem in the long run.

>Aside from the carriage return and linefeed, an apostrophe could similarly cause problems if you're concatenating strings to create SQL statement.
>
>You could continue to concatenate strings by making sure to pass all values through a function that alters the data strings so that they contain proper "escapes" to allow for proper interpretation. Aside from having to write this function, you're still going to have to alter pretty much all the lines of code where you're concatenating the SQL command strings anyway. At that point it's probably easier to simply parameterize your SQL commands (at least with that you're not left with question if you've covered all the possible situations with that "escaping" function code).
>
>as for the dangers of SQL injection:
>https://xkcd.com/327/
>
>>You are right. I will re-write my code to use the parametrized command. I am not concerned about SQL injection. But in this particular procedure it is necessary.
>>
>>>
>>>I'm not sure you will be able to find a workaround.
>>>
>>>See Message #1026953.
>>>
>>>Also, as a good practice, parameterizing helps to protect against SQL injection. For upcoming development, you might want to establish a data class which does it all for you. I do not have any direct value assignation for a SQL command since years.