What are you using? Updatable remote view? an sql string containing an update-sql statement you execute via SQLExec? A Cursor adapter? If using an SQL string, do you place the literal string in to the SQL or use parameterization?
One thing that might play a role is when you specify chinese text in code in string literals like in UPDATE sometable SET nvarcharfield='VFPAnsitext' the SYS(987) set right will convert VFP Ansi text to Unicode, but a Unicode string literal must be N'Unicodetext' not 'Unicodetext, the N prefix before the begnning quote is not optional in T-SQL, All that becomes unimportant with parameterization.
Other problems are that unless the connection is made with QUOTED_IDENTIFIER OFF the double quote " is not handled as a string delimiter in T-SQL, but as name or identifier delimiter, so you can, for example use column names with spaces and refer to them as "my column" instead of naming such a column MyColumn or my_column, as is necessary in VFP naming conventions, which don't allow spaces in names. It's not only that aspect but now "chinese text" isn't interpreted as chinese text as 'chinese text' would at least work for that english text and N'actual chinese text/letters/symbols' , but looking - depending on context - for a column or table or other object with that name/identifier. I also never saw N"string", I think it would work with QUOTED_IDENTIFIER OFF, but better leave it at only using single quotes and N'string' for Unicode.
By default QUOTED_IDENTIFIER is ON and so T-SQL only uses single quotes as string delimiters and N prefix for unicode strings in code or SQL statements. VFP can choose quote, double quote and even square brackets as string delimiters, but T-SQL doesn't. With QUOTED_IDENTIFIER OFF you can use double quotes, but then have no mean to specify names having spaces. Which is one reason a good MS SQL database developer doesn't make use of such names, depsite being able to make them work.