>Did you try running this as an SP and use nvarchar() or nchar or varbinary parameters?

It's not SQL side - it's ODBC not passing ?parameters to SQL as they were, but as the pretty much the same rules as UT currently uses, ever since it lost Unicode (which worked fine in Fox) and went western-characters-only-screw-the-rest-of-the-world way.

h=SQLSTRINGCONNECT({connect string here}, .t.)
xx="{characters which cannot be entered on UT}"
*-- TEXT BLOCK BEGIN
TEXT TO c NOSHOW TEXTMERGE
	DECLARE @c nvarchar(10)
	SELECT @c=?xx
	SELECT @c
ENDTEXT
*-- TEXT BLOCK END

?SQLEXEC(h, c, "crsResult")
SQLDISCONNECT(h)
browse

And I get half of the characters replaced with their castrated versions - carons, acutes get lost.

BTW, I will stick to my promise. If UT doesn't go back to UTF-8 or better by the time my subscription expires, it will have been my last subscription. I will not pay to be a second class citizen here. To see what I mean, try to use your powers to update my name in the users list to its proper spelling - c acute (chr(230) in CP 1250) instead of ch. Skype has it. UT had that. Email has that.

But my regular rant aside, I'd like to get back to my question: does anyone know a setting, something to put in connectstring, or to set a connection property, anything, to prevent codepage conversion in ODBC?