а) Имеется SQL server (для примера MS SQL), 2 базы, у одной collation SHIFT-JIS (i.e. codepage 932), у второй - UNICODE
b) имеется программа, которая хочет положить UTF-8 данные в базу (в частности это какая то экзотическая multbyte North Korea God's forgotten encoding). Программа спрашивает сервер про коллэйшен, видит что что то установленно. Затем создается таблица. Вот остановимся пока тут.
---
Как понять что имя таблицы (перед вызовом SQL statement "CREATE TABLE" ) валидное?
а) Запрашиваем keywords с сервера, SQLGetInfoW(in_hdbc, SQL_KEYWORDS... проверяем что они не испольуются.
б) Запрашиваем special_chars с сервера, SQLGetInfoW(in_hdbc, SQL_SPECIAL_CHARACTERS... проверяем что они не испольуются. Для MS SQL получаем разные наборы: в одном случае это только '#$' в другом случает это '#$A...Яа...я'. Сразу возникает вопрос почему в качестве спец символов вернулись все русские буквы
На сервере русской локали вообще не установлено, но на клиенской машине - есть.с) Если что то и этих двух пуктов не выполнилось, включаем (если не включенно)
SQLExecDirect(in_hsmt, "set quoted_identifier on", SQL_NTS);
запрашиваем
SQLGetInfoW(in_hdbc, SQL_IDENTIFIER_QUOTE_CHAR
и берем нужную часть of full qualified table name в IDENTIFIER_QUOTE_CHAR..
Так вот странно, для вышеперечистенного примера, пункты 1 и 2 никоем образом не указывают что имя таблицы в экзотической multbyte North Korea God's forgotten encoding должно быть quoted. И если они не quoted то таблица создана не будет. А как определить что оно должно быть quoted? Ведь оно не противоречит вроде ничему. Предложения вроде "можно все, хуже не будет" работает но не со всеми серверами. А использовать [] как панацею (тогда не придется использовать set quoted_identifier) тоже не хочется, это не универсально.
И второй вопрос? Что случится с данными в экзотической multbyte North Korea God's, конвертированными в UTF-16 и положенными в ОБЕ базы как char (все доступные char based типы) vs nchar (все доступные wchar based типы).