eftomi wrote > I found the "ultimate" place where strings are being preparedfor INSERT > INTO clause - this happens in String>>#glorpPrintSQLOn:. Not soeasy to > parametrize at a first glance. Maybe withWideString>>#glorpPrintSQLOn: but > I'm not sure how other platforms would behappy.An interesting observation > about UTF-8 and SQL Server 2019 is > here:https://sqlquantumleap.com/2018/09/28/native-utf-8-support-in-sql-server-2019-savior-false-prophet-or-both/. >
Hello Tomaz. I am the author of that UTF-8 in SQL Server 2019 post you linked to, and I think I can provide some context here. UTF-8 in SQL Server is not something you need to worry about, nor is it really an option at this point. SQL Server 2019 is still in beta, and even when officially released it will be some time before a lot of folks are using it. And for some it will take years considering that some places are still using SQL Server 2000, or 2005. If you are generating INSERT and UPDATE statements, and those include string literals, then you need to use the encoding that is expected by SQL Server. When string literals are not prefixed with an upper-case "N" they are interpreted in the 8-bit code page associated with the default collation of the database that you are currently using (likely the database that you connected to, if specified in the connection string, or the default database of the login that you connected as). If someone is using SQL Server 2019 (or newer, someday) then that might be UTF-8, but otherwise it is some Extended ASCII character set. If you are sending over Unicode data, then you can't rely on the target database using a "_UTF8" collation (as well as using it for the columns). In which case, unfortunately, you really do need to prefix all string literals with an upper-case "N". However, fortunately, for those systems that are using a "_UTF8" collation for the columns, passing in the literals prefixed with an upper-case "N" is compatible, so you don't need to have your code distinguish between the two. NVARCHAR data (i.e. string literals prefixed with an upper-case "N", and NVARCHAR / NCHAR / NTEXT columns and variables), and the T-SQL query batch itself, are encoded as UTF-16 Little Endian. Don't forget to escape embedded single-quotes ( ' ) as two single-quotes ( '' ) :-) Take care,Solomon... ----- _____________________________________________________________ SQL# — https://SQLsharp.com/ ( SQLCLR library of over 340 Functions and Procedures ) Sql Quantum Lift — https://SqlQuantumLift.com/ ( company ) Sql Quantum Leap — https://SqlQuantumLeap.com/ ( blog ) Info sites — Collations • Module Signing • SQLCLR _____________________________________________________________ -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
