Делфи XE3, Win7 проф.
Мне нужно записать в файлы DBASE 3 (старый формат) экспорт данных для DOS-подобного приложения (Clipper?). Хорошо, подумал я: драйвер MS DBASE может это сделать.
Но у меня проблемы с венгерским акцентом.
Я попробовал эту строку подключения:
Driver={Microsoft dBASE Driver (*.dbf)};DriverID=21;Dbq=c:\temp;Extended Properties=dBASE III;charSet=CP 852;Locale Identifier=1038;Character Set=CP 852;CODEPAGE=852
Как я видел, он не может записывать только файлы ANSI (приложение DOS принимает символы CP852).
Я попытался преобразовать содержимое с помощью AnsiToOEM, но некоторые символы были потеряны при сохранении. В записи я вижу хороший контент, но сохраненный файл содержит неправильные акценты. Текст теста: «árvíztűrő tükörfúrógép». В результате отсутствуют буквы «í», «ó», «Ó».
И я обнаружил странную вещь!
Если на главной форме открыто ADOConnection (в DFM свойство connect имеет значение true), то я прочитаю хорошие символы из файлов DBASE, и смогу записать их в файл — ANSI-символы будут преобразованы корректно. "И" можно, "у" можно. Этот объект ADOConnection может отличаться от средства чтения.
Если я закрою это ADOConnection в режиме IDE, открытые файлы не будут преобразованы, поэтому я увижу какие-то странные акцентированные символы и не запишу в файл хороший текст.
Это странно, потому что если я открою это соединение на FormCreate по коду, проблема появится... Я могу читать и писать записи ADOQuery, если стример ресурса прочитал активное (значение True) свойство ADOConnection "connected" из DFM!
Я не знаю, что произошло в фоновом режиме и как заставить эту процедуру преобразования символов ADO работать, но я потратил больше дней, чтобы найти работающий экспортер DBASE III, и я нашел только багоподобную вещь...
Кто-нибудь знает, что это такое? Почему кодировщик/декодер символов ADO работает только при наличии подключенного ADOConnection в DFM? Или как я могу использовать ADODB.Connection вместо объекта ADOConnection, чтобы избежать этого побочного эффекта?
Спасибо за каждую идею!