Всем доброго всемени суток. Доступ к таблице DBase через ADO. Проблема с
правильным отображением русских букв таблицы (открыватся-то открывается,
но "буковки нерусские")
Строка подключения:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Work\Work-TD\;Extended
Properties=DBASE III;Persist Security Info=False;
Если в dbf-файле кодовую страницу ппроставлять принудительно, то все нормально срабатывает. НО!!! DBF может быть с нулевым
29-ым байтом и с CP866 и c CP1251! А открывать их в режиме чтения только можно, для различных выборок (сами понимаете, что байтик)
Кроме Jet.OLEDB.4.0 пробовал еще VFPOLEDB.1 У этого провайдера и явный параметр есть на code page, но при нулевом байте не работает даже явное казание CP
Как решить проблему? Или этот косяк никак не обойти?

DBASE III в принципе не поддерживает языка таблиц. У него только один язык MACHINE

у jet-а (вернее у его dBase исама) есть настройка в реестре как он будет открывать таблицы. в дос или вин кодировке. байтик в таблице в принципе влиять не должен... тем более в 3 дибесе его вообще быть не должно (как и такой таблицы с виндовой кодировкой... они устарели задолго до появления виндовс.).

> DBASE III в принципе не поддерживает языка таблиц. У него
> только один язык MACHINE


И что это значит??? Для особо одаренных пожалуйста!


> у jet-а (вернее у его dBase исама) есть настройка в реестре
> как он будет открывать таблицы. в дос или вин кодировке.
>  байтик в таблице в принципе влиять не должен.


Но влияет именно байтик CP!
Смотрим ISAM здесь:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\ISAM Formats\dBase III
Ничего про CP, только есть Engine
Смотрим Engine:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Xbase
Вроде должно быть нормально, по умолчанию, в ключе DataCodePage=OEM! (кстати пробовал и ANSI, как кто-то советовал, но результат нулевой) НО-Но-НО!!! Правильное отображение только и только тогда, когда проставлен байтик в таблице! Вот в чем и дело-то! А именно его я менять не могу т.к. базы shared! А если 0-ой байт CP то перкодируется вообще непонятно как. И символы в гриде всякие-есть (есть и до 127 кода), хотя я специально сделал табличку, из одного поля, в которой только русский алфавит. То есть я вообще не понимаю, как перекодируется, ведь если CP866<->CP1251, то коды символов должны быть > 127 (Dec) ???
Где собака порылась?

> И что это значит??? Для особо одаренных пожалуйста!
нету в DBASE III байтика... вообще указания кодовой страницы нет, т.к. когда разрабатывался был только дос без винды.

раз у тебя есть то это НЕ дибейс три. и работать с ним скорее всего нужно по другим правилам. кстати о работе исамов, jet может работать через установленный BDE (там у тебя какие настройки?), а может через "встроенную" (и ограниченную в чем то) версию BDE.

> нету в DBASE III байтика... вообще указания кодовой страницы
> нет, т.к. когда разрабатывался был только дос без винды.

Это понятно, но другие проги, которые цепляются к этой базе, проставляют. И отследить трудно.

Поэкспереремнтировал на чистой машине и с на машине с установленной BDE. Тоже по разному ведут себя таблички с проставленной CP, и без него.
Причем правильно в обоих случаях (для DOS таблицы) только с проставленной CP

Вобщем, как бы не хотелось, а придется сначала проверять байтик! И ставить его!
Спасибо всем! Тему можно закрывать!

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

> avn72  (03.08.2009 09:08:05)  [5]

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

А может быть ты лапшу нам насчет DBASE III вешает, может не DBASE III они ждут а другое.

вообще легко проверить, выложи 2 файла, один с "правильным"  байтом другой с неправильным, открою сам и посмотрю. только вечером, счас работы много.

> sniknik  (03.08.2009 11:22:08)  [8]

Можно не тратить время, dBase III по определению не поддерживает это поле, по спецификации. Поддержка языка таблицы, а это именно это поле, появилась начиная с dBase for Windows, кроме того для русского только 866 кодовая таблица.

Anatoly Podgoretsky ©   (03.08.09 12:07) [9]
я это знаю, но как предполагал ранее у него скорее всего не dbase III, и даже в этом случае при указании движку (jet) кодировки он не обращает внимание на байт в файле, ну, насколько помню, вот с парадоксом было обратное.

> sniknik  (03.08.2009 15:21:10)  [10]

Поскольку jet работает с dBase III - dBase IV поэтому кодировка не актуально, в отличии от Борланда они не стали делать извращения, а отнеслись более лояльно к формату, единственно, что они позволили себе так это перекодировку OEM/ANSI

Не думал, что тема продолжилась!


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


Если найдешь время проверить, могу выслать и базки и програмульку и исходник, потому что результаты мои что-то уж сильно расходятся с вашими, хотя тестил на двух машинках - w2k3 c BDE и на девственно чистой w2k

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

> w2k3 c BDE и на девственно чистой w2k
сразу можно сказать результат может быть разный, при использовании jet-ом установленного BDE одни настройки (использование его ты наверняка не отключал) , без установки другие.

> сразу можно сказать результат может быть разный, при использовании
> jet-ом


Так в том то и дело! О чем я и говорил. Результаты разные! Поэтому я и решил байт проверять, потому что проверять на разных машинах настройки Jet и BDE и менять их - это нехорошо. Я решил в данном случае как можно меньше править реестр, неизвестно, как себя поведут другие сторонние проги, которые могут пользоваться этими-же настройками. И гемора у меня будет намного больше.

Так что спасибо! Не стоит проверять.

О каком байте может идти речь, при

> Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Work\Work-TD\;Extended
> Properties=DBASE III;Persist Security Info=False;

Оно в принципе не поддержано, язык таблицы впервые появился в версии dBase for Windows. До этого никаких языков не было, только MACHINE, при этом под этим исключительно понимается OEM, для JET сделано извращение для покрытия извращений других проеkтировщиков - это переключение OEM/ANSI хотя ANSI в принципе быть не может, DBASE III это для ДОС

Дальнейшее извращение это двойная поддержка БДЕ - родного БДЕ и из JET, по JET я уже указал, но когда стоит большой БДЕ, то используются его языковые драйвера, но все равно для DBASE нет ANSI драйверов в принципе.

Третье извращение - это dBase VII тебя правда не касается, то там еще появилась поддрежка шрифтов, языки реализуются через шрифт :-)

> пробовал еще VFPOLEDB.1

Это бы решило проблему, только нет совместимости с dBase по индексам и мемо полям.

И все это не включает извращение над байтом язык таблицы, когда он установлен для тех форматов, где его быть не должно и непредсказуемое поведение большого БДЕ

И резюма, для JET, как правило, достаточно поиграться с параметром OEM/ANSI.

> потому что проверять на разных машинах настройки Jet и BDE
> и менять их - это нехорошо.

Это очень нехорошо, но слава богу, что их можно задать локально в строке подключения, название параметра не помню.

Оказывается, что неправильная кодировка при нулевом байте возникает при стандартных установках BDE (т.е. LangDriver='ascii' ANSI)


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


Уже все глаза проглядел на:
http://msdn.microsoft.com/en-us/library/aa140022(office.10).aspx#adoproperties_extendedsettings

Не нашел!

> Оказывается, что неправильная кодировка при нулевом байте
> возникает при стандартных установках BDE (т.е. LangDriver='ascii'
> ANSI)


Все что нужно, это добавить в реестр в ветку
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\xBase]
значение BDE типа DWord со значением 2.
Причем это не повлияет на работу остальных приложений.
Вот пруфлинк: http://support.microsoft.com/kb/307455/EN-US/

Автор давно уже умер, а ты только проснулся.