DAiMorА в чем увидели проблему для простых кашеваров?Если Cache и Ensemble сливаются в экстазе в единый продукт, то прощайте, 8-битные установки Cache.

Для кого-то это может стать проблемой.

AlexKB...а для связи с оборудованием по промышленным 8-битным протоколам - это гемморой!Unicode-овские данные, укладывающиеся в национальную кодовую страницу, без проблем перекодируются что в CP1251, что в CP866; у нас лаборатория нормально себе работает на Unicode-установках, там тоже протоколы 8-битные.

Основная проблема мне видится в отсутствии универсального подхода к конверсии данных. Глянул я на рекомендованную когда-то утилиту ... очевидно, что годится она лишь для простейших случаев. Автоопределение $list-ов - это конечно здорово, но что если в БД хранятся двоичные данные, которые надо оставить в том же формате? Утилита про это ничего не знает. Поэтому тем, у кого сложные структуры данных, неизбежно придётся разрабатывать что-то под себя, а это тоже работа, причём заказчикам будет сложно объяснить, а на хрена, когда "и так всё работает".

Даже наша, немаленькая по СНГ-шным понятиям, фирма едва ли стала бы смотреть в сторону Юникода, если бы не потребность в расширении рынка.

DAiMor,

Наш софт работает в Юникоде примерно с 2010 года, но исторически сложилось так, что используется он преимущественно за границей (пока что это Казахстан), ну и у нас на фирме, конечно. Конверсией баз мы не занимались, заливка данных делалась через наш механизм обновлений. Из достижений последних лет: кроссплатформенный формат файла выгрузки глобалов (близкий по компактности к %GOF) и инструмент обмена данными в этом формате. Поддерживается двухсторонний обмен данными между установками Unicode и 8-bit.