Encoding issue with Database Updates.sql

All right, so i had the opportunity to use fancy quotes with database updates the other day and ran into an issue where what i put into the database (blah blah blah “left and right hand quotes here” blah blah blah) came out with a confused character render (blah blah blah ?left and right hand quotes here? blah blah blah). And in case it’s not obvious off the bat (what, you don’t carry a magnifying glass?) - the issue i’m having is between dumb / straight quotes (") and typographic / smart quotes (“ and ”).

I did a little testing and it looks like the issue is between Database Updates.sql and SQL Server. I tried the query from SQL Server Management Studio and it put the fancy quotes into the database without an issue. Attempting the same insert statement from Database Updates gave me question marks. The column in question is an nvarchar. I’ve tried prefixing the string with an N, because this should indicate to the server in an explicit way that the string should be treated as an nvarchar. The prefix didn’t have an effect on either the successfully executing query from the Management Studio (it was still successful), or on the quietly glitchy query in Database Updates (it still replaced my fancy quotes with question marks).

Any thoughts on why this might be or if there’s a thing i can do differently to prevent it? Thanks!


I don’t have a solution, but the problem may be caused by what we’re doing on this line:


When the EWL Development Utility is updating the database, it uses this line of code to send the script to sqlcmd, the command-line SQL Server client. It’s possible that due to their DOS roots, Windows command-line parameters are limited to ASCII characters or something; I’m not sure. If you could reimplement the method so it sends the script to SQL Server in another fashion (via ADO.NET maybe?), the problem might be solved.

1 Like