Выполняем следующий запрос:

create table test (fld char(4));
insert into test (fld) values ('123');
insert into test (fld) values ('1234');
insert into test (fld) values ('12345');

не смотря на то, что размер строки в последнем операторе превышает размер поля, вставка происходит нормально, и при выполнении `select * from test` с помощью sqlite3.exe на выходе получаем правильные значения поля fld ('12345' в том числе). это одна из особенностей sqlite, и это меня устраивает. а вот ODBC/VCL - нет. при выполнении вышеуказанного селекта с помощью TADOQuery/TADOTable в Delphi/Builder получаем E_FAIL.

исходники odbc драйвера скачал, но что-то подсказывает, что проблема даже не в нем. кто подскажет, как бороться?

и вот еще что выяснилось.
когда попробовал подключить источник данных к Excel, получил в результате запроса `select * from test` следующий результат: '123', '1234', '1234'. т.е. в отличие от sqlite3.exe он обрезал избыточные символы, но исключения не возникло. следовательно, проблема в VCL (ADODB в частности). понимаю, что к sql это уже не имеет отношения, но наверняка многие работают с этой библиотекой и смогут подсказать если не решение, то хотя бы где его искать.

в источнике данных выбираем "No WCHAR" и начинает работать как в Excel'е, т.е. длинные строки обрезаются...

1. работать с базой будут, естественно, другие люди, которые могут написать что угодно. приведенный пример упрощен, количество таблиц и текстовых полей в них достаточно велико. вытаскивать из всех полей таблиц TField.DataSize и записывать в каждый TEdit.MaxLength мне не сподручно.
2. SQLite был выбран помимо всего прочего именно из тех соображений, что в отличие от других доступных субд он практически не накладывает ограничений на тип и размер полей ( наверняка Вы уже это читали, но все же ).
3. после отключения юникод-версии драйвера программа стала работать корректно. юникод-версия экспериментальная. как я понял из переписки с разработчиком драйвера, ошибка будет исправлена в ближайшее время.
4. LONG VARCHAR меня не устраивает по ряду причин, которые я не буду здесь приводить.
5 (офф). извини, конечно, но вот если я и записываю char(5) в char(4), то это либо действительно мне нужно (см. 2), и реторика типа "ЗАЧЕЕЕМ ты на свет появился?!" здесь ни к чему, либо я просто дурак, что тоже совсем не обязывает тебя отвечать на дурацкие вопрсосы.

White OwlНу и очень плохо что тебе это "не сподручно". Надо. Если где-то заложено ограничение, его надо учитывать.
ну если тебе уж тааак интересно, то это не ограничение, а указание для компонентов класса TDBGrid, какой ширины устанавливать соответствующие столбцы по умлч.

White OwlЕсли это является решающим фактором при выборе БД, то я тем более не понимаю почему нельзя объявить все поля TEXT заранее. Зачем вообще использовать char(X) если этот самый char(X) в sqlite является всего-лишь ущербным TEXT?
Задавая поле char(4) ты сам, сознательно накладываешь на себя ограничение. Зачем его накладывать если ты изначально знаешь что ты не будешь ему следовать???
во-первых, см выше.
во-вторых, поле типа TEXT интерпретируется компонентами VCL как LONG VARCHAR и отображается "(Мемо)" вместо содержимого поля. для всех таблиц отдельно прописывать всякую ерунду типа вычисляемых полей я не намерен, ибо формы приложения в основном универсальные.

White OwlНет, это не нужно. Это никогда не нужно и очень вредно.
Сегодня ты сам работаешь с базой, завтра ты уйдешь в отпуск и эту базу повесят на другого человека - что он сделает когда увидит char(4) в описании таблицы и char(5) в клиенте? Правильно одно из трех: либо исправит базу, либо клиента, либо вытащит тебя из отпуска.
сегодня и завтра в sqlite не накладываются ограничения на длину строковых полей, и именно поэтому, если я, "другой человек" и клиент передумаем, сойдем с ума или сдохнем - база будет функционировать корректно.
Вообще, я задавал вопрос о корректности работы драйвера. О функции, которую он выполнять должен, но не выполняет. все твои ответы - один большой оффтоп. во всяком случае мне они точно не помогли. я рад, если они как-то способствуют твоему самоутверждению.

White OwlА я не люблю дураков и потому пытаюсь их научить как надо делать правильно.
а, ну тогда ясно... и где твои 12 апостолов? небось судорожно смывают "primary key", "unique" и "check" с полей таблиц своих неправедных баз и удаляют триггеры, ибо при импорте данных в какой-нибудь Excel они не работают?

ограничение длины текстового поля - пережиток struct'ов в плоских файлах. вот о чем нужно забыть. и если разработчикам наконец удалось снять отягощающие написание программ ограничения, их нужно поддерживать, активно используя новые возможности и расширяя их. а тебе, судя по всему, по душе парадокс, и больше ничего не надо).

благо драйвер с открытым кодом. ошибка исправлена, тема закрыта.)