dbGrid 1.8rc1 показывает другие данные чем в 1.6

[t-ea]

Скачал я 1.8rc1 и был неприятно удивлён. Стало мне уже не до печати.
tdbStringGrid показывает «кракрозяблики», в то время как версия 1.6 показывала всё хорошо.
Внизу два снимка экрана, один то что показывает программа скомпилированная в версии 1.6, другой соответственно 1.8rc1. В самом проекте ничего не менялось. На форме находятся пять компонентов: tmseODBConnection, tmseSQLTransaction, tmseSQLQuery, tmseDataSource и tdbStringGrid.
ODBC драйвер используется родной Microsoft'овский, но думаю это не из-за него, т.к. 1.6 всё показывает правильно.
Что делать?

[debi12345]

У Вас в БД данные в какой кодировке хранятся ?
Если в юникоде, то :

- скажите об этом MSE*, через {connection.controller.options:= dbo_utf8} и/или {query.controller.options:= dso_utf8}
( не пристало MSE* искать способ узнавать внутренние кодировки БД - слишком это зависит от текущей реализации БД )

если нет и кодировка БД отличается от кодировки GUI операционной системы ( вроде БД=koi8 vs гэймшеллка=cp1251), то :

- придется искать способ скормить в настройках соединения что-то типа "CLIENT_ENCODING=win" ( использую такое для PostgreSQL в Дельфях )

Параметр Charset ODBC-соединения по идее фикция ( не по вине MSE* ) и работать не должен ( хотя не проверял).

Добавлено спустя 1 час 2 минуты 35 секунд:
Кстати, ODBC-механизм в MSE* никто пока конкретно не использовал и потому не протестировал в деле (Мартин вообще удивился - нафига, думаю потому, если есть ZeosDBO ) - поэтому может уйти несколько дней на вылизывание. Например, у меня таблица M$ Access OLEDB 4.0 вообще не открывается.

[t-ea]

Работаю в Windows XP SP2, естественно 1251 кодовая страница.
Сейчас попробовал три ODBC-соединения (все являются системными):
1. Firebird 1.5: кодировка cp1251, — данные показываются неправильно.
2. MS Visual FoxPro: кодировка cp866 — данные показываются неправильно (картинка выше).
3. MS SQL Server 200(предпоследний): кодировку не знаю — данные показыаются правильно.

И ещё раз повторю на всякий случай: ничего не меняя в проекте, компилирую программу версией 1.6, всё замечательно показывается.
Насколько я заметил, MSE показывает первые два-три символа каждого поля правильно, а вот потом что-то где-то не так. В моём примере это видно по полям SOCR, CODE, в NAME тоже самое, но первых символов там не видно, так как содержимое ячейки отображается в несколько строк.

Сразу добавлю, о чём хотел спросить чуть позднее.
Основная рабочая база на MS SQL-Server. В моих попытках освоить MSE, всяких проб и экспериментов, делал простую форму, точно так же ODBC, Transaction, Query и Grid. Всё работает.
После этого, при попытке добавления на форму нескольких компонентов tmse*field драйвер ODBC начинал сообщать о раззных ошибках: то неверный дескриптор, то «25678.17684.89144» не явлется правильным числом (сами цифры и тект последнего сообщения точно не помню но смысл такой).
Сейчас у меня на форме лежит пять stringfield'ов, один из них не подключен — всё работает, подключаю пятый — получаю ошибку «неверный дескриптор», т.е. я даже в design-time не могу активировать SQLQuery.

Без ODBC мне не обойтись, есть одна старая база с которой можно работать только через так.

Попробую сегодня узнать в какой кодировке хранятся данные на MS SQL Server (знать бы как) и вечером опишу подробнее все свои настройки.

[Sergei I. Gorelkin]

Сдается мне, что цифры в последнем столбце должны отображаться корректно вне зависимости от кодировок. Т.е. бага не в кодировках (или не только в них)

[debi12345]

Работаю в Windows XP SP2, естественно 1251 кодовая страница.
Сейчас попробовал три ODBC-соединения (все являются системными):
1. Firebird 1.5: кодировка cp1251, — данные показываются неправильно.
2. MS Visual FoxPro: кодировка cp866 — данные показываются неправильно (картинка выше).
3. MS SQL Server 200(предпоследний): кодировку не знаю — данные показыаются правильно.
...

Повторяюсь, не завязывайтесь на ODBC ) - он о-о-чень сырой (причем не в MSE*, а в FPC SQLDB - которым MSE старется по-возможности, там где нет глюков, пользоваться ). Мартин вообще удивился, что что-то когда-то там работало.
Взамен этого есть статическая библиотека ZeosDBO - поддерживающая в том числе все основные коммерческие бэкэнды. В MSE* встраивается и работает без проблем. Поддерживают ее толковые и серьезные ребята. Детали - см. "zeos.txt" в корне MSE* SVN. Мелкий минус Zeos - не все суперфишки MSE*-компонентов на ней возможны, но ничего не падает и не сыплет исключениями.

Если все равно ODBC необходим в чистом виде - придется несколько дней усилено тестить, слать тесткэйсы Мартину, вести сним конкретный диалог ( на английском ). Один проблемный тесткэйс по этой теме ( доступ к таблицам M$ Access OLEDB 4.0 ) Мартину уже выслан.

ПС:
По любому, если нужна безглючная работа с БД через нативные библиотеки на уровне БД-компонентов без тупого кодирования, то альтернативы MSE* пока но видно - ессно, в части вылизанных бэкэндов ( PostgreSQL = аналог оракла, мартиновский фаворит FireBird, мой обожаемый SQlite3, memdataset=local_mode). Другие бэкенды тоже будут незамедлительно вылизаны - но только с серьезной помощью тех, кому он понадобятся. Например,MySQL пока не идеален - потому никто пока серьезных ( из реальной жизни ) проектов на нем не делал.

Добавлено спустя 1 час 43 минуты 40 секунд:
От Мартина к @t-ea (freepascal.ru):
----------
Please send a testcase with small database and info where to get the ODBC
driver and how to setup the environment. I don't have a newer MS-Access
installation.
----------

[Vadim]

Если речь идёт о MS SQL 2000, то кодировка базы, с 99% вероятности, cp1251.

[Brainenjii]

[offtop]
t-ea: Здравствуйте, почему в версии 1.6 крякозябр не было, а в 1.8 - есть?
debi12345: Попробуйте указать UTF8 в подключении к базе, а вообще, ODBC очень кривой сам по себе
t-ea: я не знаю, какая кодировка, но почему в версии 1.6 не было НИ ЕДИНОЙ крякозябры, а в 1.8 - сразу в 2 базах!
debi12345: ODBC очень кривой, не используйте его
t-ea: ВЫ НЕ ОТВЕЧАЕТЕ НА МОЙ ОТВЕТ!
[/offtop]
^_^ Извините, напомнило и не сдержался ^_^

[Vadim]

t-ea
Напишите здесь, пожалуйста, основные настройки Вашего tmseODBConnection.

[debi12345]

t-ea: я не знаю, какая кодировка, но почему в версии 1.6 не было НИ ЕДИНОЙ крякозябры, а в 1.8 - сразу в 2 базах!
..
Мартин вообще удивился, что что-то когда-то там работало.
..
он о-о-чень сырой (причем не в MSE*, а в FPC SQLDB -

Здрасте, в двух соснах заблудились...
100% кое-что в FPC "подправили", и оно перестало координироваться с MSE*. И вероятно, что в готовом бинарнике 1.6 было зашито еще "правильное" состояние FPC. А рекоординацией Мартин не занимался из-за остсутствия заявок и собственной надобности в ODBC.

ПС:
Приглашаем на ньюс-конференцию "public.mseide-msegui.talk" на сервере "news.grid-sky.com". Хоть и тюремное название ( "небо в клеточку" ) - но народ там не кусачий. ПроЯвите профессионализм и терпение, помогая вылизать ODBC - большое дело сделаете.

Добавлено спустя 4 часа 27 минут 23 секунды:
Мартин с моим тескэйсом получил нормальную кириллицу даже на своей латинской локали.
БД в ODBC-тесткэйсе - M$ Access из M$ Office 2003, внутреннее хранение = юникод,

[t-ea]

Про MS SQL ничего не узнал… если нужно будет, то завтра расскажу.
Насколько я понял проблема возникает с полями типа CHAR, с VARCHAR всё нормально.
Ниже снимки экрана, и на всякий случай, три базы — GDB, DBF в cp866 и DBF в 1251.

Firebird ODBC Drivers 1.2.1 (1.2.0.69)
Visual FoxPro ODBC Driver

Добавлено спустя 4 минуты 11 секунд:
продолжение…

Добавлено спустя 2 минуты 3 секунды:
Настройки ODBC:

[Vadim]

t-ea
Всё запуталось ещё больше.
Давайте, для начала, определимся, с каким именно типом базы данных Вам нужно работать через ODBC. Иначе никаких толковых советов Вы не дождётесь.

[debi12345]

Насколько я понял проблема возникает с полями типа CHAR, с VARCHAR всё нормально.

От Мартина :

svn trunk 2356
* ODBC SQL_CHAR mapped to ftstring.

Перепроверьте !

Добавлено спустя 3 минуты 10 секунд:
Рекомендую создать тестовую таблицу со всеми возможными для ODBC типами данных, включая бинарные и блобы - и на ней добиться корректных записи/чтения. Именно на таком тесткэйсе, так мы добились 100% рабочего SQLIite3.

[t-ea]

Да, теперь всё стало как и раньше…

t-ea
… с каким именно типом базы данных Вам нужно работать через ODBC…

Не уверен что правильно понял вопрос, но: MS SQL и DBF.

[Vadim]

Не уверен что правильно понял вопрос, но: MS SQL и DBF.

Совершенно правильно. Это и требовалось.
По поводу DBF.
А Вы не хотите для общения с DBF использовать класс, который уже есть в FreePascal под названием TDBF? Работает быстрее, чем через ODBC. Правда там нет поддержки SQL-запросов. Преимущество в том, что Вам не надо будет делать настройки доступа к данным в двух разных - в Администраторе ODBC и в Вашей программе, все настройки нужно будет сделать только в Вашей программе.

[debi12345]

FreePascal под названием TDBF

Если не нужно адаптировать имеющиеся DBF БД, а нужно просто маленькая сверхбыстрая БД для новых проектов - рекомендую SQlite3. Самое главное - к нему есть SQL-доступ.