Проблему уже один раз описывал, но решения так и не нашёл.  Итак.
Есть  БД, созданная под 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.
>
> Я не совсем понимаю, где ты видишь тут достоинство.


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

> Firebird doesn't match the standard (SQL92) isolation levels
> exactly.


Oracle тоже doesn't match the standard (SQL92) isolation levels exactly.
И что из этого должно следовать ?

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


Сходи на sql.ru

От меня ты так же не слышал о накрывшейся тем же предметом базы под Firebird. Что из этого следует ?

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


Вот с этого и нужно было начинать! :)

> Это не аргумент вообще
наоборот, личный опыт это единственный значимый аргумент, если для себя... и чем он ближе тем лучше.

иначе получается как в анекдоте -
СССР.
Лекция общества "Знание"
Лектор: В городе А построили завод.
Голос из зала: Да был я в городе А, только котлован вырыли - и тот уже в озеро превратился.
Лектор (недовольно): А в городе Б - фабрику.
Голос из зала: Да был я в городе Б, только фундамент сделали - да и тот уже бурьянами зарос.
Лектор (раздраженно): А вам, товарищ, надо реже по всему Союзу шастать, а чаще посещать лекции общества "Знание"!

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

Бывает, но очень редко

> Бывает, но очень редко
у нас на одном таком, клиент узнал, что у него оказывается mssql стоит... и вообще у программы есть база. ;)
потом оказалось диск "накрылся", просто в первую очередь "пострадали" крупные файлы, база в том числе.

кстати, другого и не помню ничего. а клиентов было довольно много.

> потом оказалось диск "накрылся", просто в первую очередь
> "пострадали" крупные файлы, база в том числе.


Так это проблемы железяки, а не "ядра". А вот чтобы у базы "слетели индексные таблицы" в результате (вот уже не помню ,что там конкретно было. То ли бэкапили базу, то ли ещё что-то делали. Вроде бы помню, что были незавершённые транзакции на тот момент) каких-то там действий - не припоминаю.

> Ega23  (02.11.2011 10:29:26)  [26]

Бывает, но обычно лечится просто, или вообще такое не допускается
профилактическими методами.

> Anatoly Podgoretsky ©   (02.11.11 12:09) [27]
>
> Бывает


Да, блин, я же не отрицаю того, что сломать можно всё, что угодно.

У нас работает MSSQL 2005 x64 24x7 очень давно,проблем с базой никогда не было. На серваке в среднем сидит 1000 чел и около 3000 коннектов.

Используем грязное чтение т.к. в некоторых ситуациях нет смысла ждать выполнения транзакций и выстраивать очереди.

Есть клиенты у них тоже крутится MSSQL 2005. Нагрузка конечно не большая. У них даже админов нет, серверная закрыта. Админов приглашают если в сети новые компы появляются. А по вопросам MSSQL никто и не обращался уже пару лет.

FB у нас тоже есть крутится так же 24х7 под линуксом, но честно говоря ничего не скажу т.к. не касаюсь к нему.

Если не ставить обновления и вообще не производить никакой профилактики, то 2005 работает годами, пока железо не погибнет. Если ставить обновления, то перезагрузка раз в месяц, но не из-за MSSQL сервера.

> Ega23 ©   (02.11.11 12:24) [28]


> Да, блин, я же не отрицаю того, что сломать можно всё, что
> угодно.

Даже х..Несмотря на то, что это гидравлика..:-)

Дали дураку стеклянный член, так он его разбил и еще и порезался.

> Anatoly Podgoretsky ©   (04.11.11 12:51) [32]

Хоть и флуд, но смешно! Надо запомнить...:-)