Проблему уже один раз описывал, но решения так и не нашёл.  Итак.
Есть  БД, созданная под InterBase с помошью  SQL-запросов. В частности, в ней есть строковые поля типа:


(здесь пытался задавать разные варианты character set - не помогает).
Подключаюсь к этой БД из Delphi XE (это важно: с Delphi7 было всё ОК!). Создаю на форме TDBGrid  в которой один из столбиков соединён с этим строковым полем (могу задать в свойствах TDBGrid любой Font и CharSet - не помогает). В итоге, при работе программы написать в этом строковом поле что-то кириллицей не выходит: после транзакции выскакивают вопросительные знаки или каракули. При подключении к БД в свойствах TIBDataBase тоже пытался указывать CharacterSet = win1251. Возникает ошибка что-то типа "Не могу перевести между разными CharSet" уже при запуске программы. Что делать? И ещё. Поля типа Memo (BLOB) совершенно нормально воспринимают кириллицу безо всякой возни с этими CharSet, но их к TDBGrid не подключить...

Почему бы не пользоваться нормальными СУБД и средствами разработки, а не стрёмными поделками?

> Есть  БД, созданная под InterBase


СУБД какая? InterBase? Или FireBird? Версия?


> При подключении к БД в свойствах TIBDataBase тоже пытался
> указывать CharacterSet = win1251. Возникает ошибка что-то
> типа "Не могу перевести между разными CharSet" уже при запуске
> программы. Что делать?


Delphi XE - юникодная. Попробуйте CharacterSet = utf8.


> Поля типа Memo (BLOB) совершенно нормально воспринимают
> кириллицу безо всякой возни с этими CharSet


Это же просто набор байтов и то, как их интепретировать, зависит от клиентского приложения.


> DiamondShark
> Почему бы не пользоваться нормальными СУБД


Автор где-то интересовался вопросом выбора СУБД?

> СУБД какая? InterBase? Или FireBird? Версия?

Все равно поделка

> Delphi XE - юникодная. Попробуйте CharacterSet = utf8.

Автор, ты пойми, в Delphi XE по умолчанию не ANSI, и не Win-1251, а Юникод.

>
> > СУБД какая? InterBase? Или FireBird? Версия?
>
> Все равно поделка


Это очень качественный программный продукт, при разработке которого основные усилия немногочисленных его разработчиков направлены не на бесконечное усовершенствование всевозможных и бесчисленных рюшечек, а на развитие ядра СУБД. В этом вопросе разработчики, по моему мнению, весьма преуспели.
В мире работает бессчетное количество в том числе высоконагруженных систем, годами эксплуатируемых без перезагрузок и сбоев в режиме 24х7, в основе которых лежит СУБД FireBird. Давайте возьмем и также назовем все эти системы "поделками". А тогда как следует называть продукты нашего творчества?

> годами эксплуатируемых без перезагрузок и сбоев в режиме 24х7

Страшно представить.

Оно и видно

> Автор, ты пойми, в Delphi XE по умолчанию не ANSI, и не
> Win-1251, а Юникод.

Разумеется, я это знаю: потому и пытаюсь сменить кодировку. Но что конкретно делать в моём случае? Пытаюсь поменять в свойствах компонента TIBDataBase Character Set со значения 'None' на 'UTF8' - бестолку! Сразу - в Delphi XE при подключении к БД (ещё до компиляции) выскакивает ошибка: "Bad parameters on attach or create DataBase. CHARACTER SET UTF8 is not defined". Где копать: в InterBase или в Delphi?

> Это очень качественный программный продукт, при разработке
> которого основные усилия немногочисленных его разработчиков
> направлены не на бесконечное усовершенствование всевозможных
> и бесчисленных рюшечек, а на развитие ядра СУБД. В этом
> вопросе разработчики, по моему мнению, весьма преуспели.

Нормальная поддержка кодировок -- это "рюшечки".
Зато ядро.
Кому нафиг нужно "ядро", из которого невозможно получить обратно свои данные?

Это идеология всего опен-хрень движения.
Вам нужен юникод? Идите лесом со своими рюшечками, у нас ядро!
Вам нужен удобный интерфейс? Лососните тунца со своими рюшечками , у нас ядро!
Вам нужна качественная поддержка промышленных стандартов? Горите в аду  со своими рюшечками , у нас ядро!

Тяжёлая, мастерски выполненная работа.
http://riain.ru/ab30bf8.jpeg
Только бесполезная.

> Где копать: в InterBase или в Delphi?

Копаешь сначала сюда:
http://www.microsoft.com/sqlserver/en/us/default.aspx
потом сюда:
http://www.microsoft.com/visualstudio/en-us

Если нет денег, то копаешь по ключевым словам "Express edition", всё равно оно будет функциональнее того трэша, из какого ты пытаешься что-то слепить.

> В мире работает бессчетное количество в том числе высоконагруженных
> систем, годами эксплуатируемых без перезагрузок и сбоев
> в режиме 24х7, в основе которых лежит СУБД FireBird.


Я так скажу. Я не слышал о крахе базы под MSSQL, Oracle или Postgres. Падение сервера - слышал. Но вот так, чтобы после его поднятия база не читалась - такого не слышал. Про FB - слышал. Не скажу, что дофига раз, но два-три - точно.
Ну и таки согласен с Шарком: за отсутствие read_uncommitted и INFORMATION_SCHEMA, а также за свои бесконечные транзакции - гореть в аду.

> Но вот так, чтобы после его поднятия база не читалась -
> такого не слышал


сходи на sql.ru, послушай

> сходи на sql.ru, послушай


Я не про "вообще в мире", я про личных знакомых в реальной жизни.

> Вам нужен юникод? Идите лесом со своими рюшечками, у нас
> ядро!


Юникод поддерживается в FB очень давно, уровень поддержки - великолепный.


> Вам нужен удобный интерфейс? Лососните тунца со своими рюшечками
> , у нас ядро!


Интерфейс чего с чем?
Если имеется ввиду админский интерфейс, то есть IBExpert - очень качественный и достойный программный продукт. По крайней мере по сравнению с MS SQL Server Management Studio (в части самых различных возможностей). Хотя не сомневаюсь, что и для SQL Server существуют куда более удобные средства. Но не будем забывать, что IBExpert - это все-таки коммерческий продукт, который (спасибо его авторам) достается нам, русскоговорящим, на халяву.


> за отсутствие read_uncommitted и INFORMATION_SCHEMA, а также
> за свои бесконечные транзакции - гореть в аду.


read_uncommitted это "грязное чтение", если не ошибаюсь? Имхо, его отсутствие является скорее преимуществом, чем недостатком.
Насчет транзакций - не совсем ясно, что с ними не так. Поясните, где Вы видите трагедию?
На мой взгляд, и механизм транзакций и механизм версионности реализован в FB (скорее даже в Interbase) блестяще, на очень (возможно, самом) высоком уровне. Другое дело, что литературы по FB крайне мало (выходит может раз в 5 лет), в связи с этим на Delphi-форумах периодически возникают одни и те же вопросы, связанные с работой транзакций. Так уж повелось, что Delphi - наиболее популярная среда разработки клиентский программ для FB.

> Но вот так, чтобы после его поднятия база не читалась -
> такого не слышал. Про FB - слышал. Не скажу, что дофига
> раз, но два-три - точно.


Тут, конечно, речь идет о важных рюшечках: если в промышленных СУБД настройка и планирование бэкапов осуществляются достаточно просто, есть подробная документация, имеется удобный интерфейс, то с FB бывает чуть посложнее. Но все же имеются необходимые средства.

Если же не настроить резервирование, то после сдыхания HDD не спасет никакая СУБД (полный журнал транзакций на отдельный HDD я отношу все-таки к резервированию, т.к. шансы восстановить данные повышаются).

> Я не про "вообще в мире", я про личных знакомых в реальной
> жизни.


Это не аргумент вообще

> На мой взгляд, и механизм транзакций и механизм версионности
> реализован в FB (скорее даже в Interbase) блестяще, на очень
> (возможно, самом) высоком уровне.


http://web.firebirdsql.org/dotnetfirebird/transaction-isolation-levels.html
Firebird doesn't match the standard (SQL92) isolation levels exactly.

Я не совсем понимаю, где ты видишь тут достоинство.


>  то есть IBExpert - очень качественный и достойный программный
> продукт. По крайней мере по сравнению с MS SQL Server Management
> Studio (в части самых различных возможностей).


"Позвольте Вам не позволить!" (с)
Работал и с тем и с другим. IBExpert хорош не потому, что он такой весь распрекрасный, а потому, что альтернатива - в isql команды набирать.

> Это не аргумент вообще


Тем не менее. Я не слышал ни от тебя, ни от Петрухи Абрамова, ни от Серёги Маслова, чтобы вот так вот накрылась база под Ораклом. Я не видел ни разу, а также не слышал от сотоварищей, чтобы MSSQL-ная база накрылась медным тазом.
Про FB - слышал.

Собственно, холивар не нужен, у каждой СУБД есть свои достоинства, у каждой - недостатки. Я могу много аргументов привести, чем FB лучше MSSQL. И наоборот, много аргументов, чем MSSQL лучше FB. Только вот нафига?

> Firebird doesn't match the standard (SQL92) isolation levels
> exactly.
>
> Я не совсем понимаю, где ты видишь тут достоинство.


Насколько мне известно, все эти стандартны сочинялись уже под готовую реализацию СУБД. Некто очень умный изобрел СУБД, с массой недостатков, но вместо того, чтобы избавляться от недостатков, назвал их "стандартом".