Проблема:
писал я программу, конвертирующую дбф в оракл. Работала. Заменили базу на обновленную - вместо русских символов стали кракозябы появляться. Раньше работало все. В фаре по Ф3 смотрятся оба файла в одной и той же кодировке (DOS - cp866 вроде) одинаково примерно (ну данные немного изменились). А читаться отказывается нормально. Коннект через TADOQuery посредством ODBC.
Предположение:
в файле дбф можно, походу, указывать кодировку, но как ее изменить, или как правильно указать ее при подключении?

Насколько я помню - dbf бывает разный.
У тебя какой? FoxPro, Paradox, DB4?

Ну коннекчусь я к нему как к Microsoft Visual Fox Pro, а там не знаю, мож этот драйвер разные понимает форматы. Хотя я в екселе пробовал в разные виды сохранять - не получилось все равно. Формат вряд ли изменился - они в той же самой программе набирали вроде.

Ну FoxPro файлы достаточно простые, если только в последней версии ничего не переделали.
Их довольно легко можно читать напрямую, если, конечно, не нужны функции SQL.
Если интересно, могу в понедельник из хелпа вытащить описание заголовка. Видимо драйвер ODBC неправильно из заголовка два байта обзначающие страницу кодировки читает. Как это победить - х.з.

Ну мне только "селект *" нужен, могу и руками сэмулировать, конечно. Но если не трудно, глянь, что сможешь. А где это такой хелп есть?

В старых версиях FoxPro в хелпе был технический раздел где приводилось описание структуры всех файлов.

Вот. Ели людей в старом офисе поймал - Новый Год это вам не шутка

Цитата

Visual FoxPro uses tables to store data that defines different file types. The file types that are saved as table files are: • Table (.DBF) • Database (.DBC) • Form (.SCX) • Label (.LBX) • Menu (.MNX) • Project (.PJX) • Report (.FRX) • Visual Class Library (.VCX) Because these files are actually tables, you can use and browse them in the same way that you browse any .DBF file. A table file is made up of a header record and data records. The header record defines the structure of the table and contains any other information related to the table. It starts at file position zero. The data records1 follow the header (in consecutive bytes) and contain the actual text of the fields. For information about the table structures of the different file types, see Table Structures of Table Files. The length of a record (in bytes) is determined by summing the defined lengths of all fields. Integers in table files are stored with the least significant byte first. Table Header Record Structure Byte offset Description 0 Type of file 0x02 FoxBASE 0x03 FoxBASE+/dBASE III PLUS, no memo 0x30 Visual FoxPro 0x43 dBASE IV SQL table files, no memo 0x63 dBASE IV SQL system files, no memo 0x83 FoxBASE+/dBASE III PLUS, with memo 0x8B dBASE IV with memo 0xCB dBASE IV SQL table files, with memo 0xF5 FoxPro 2.x (or earlier) with memo 0xFB FoxBASE 1 – 3 Last update (YYMMDD) 4 – 7 Number of records in file 8 – 9 Position of first data record 10 – 11 Length of one data record (including delete flag) 12 – 27 Reserved 28 Table Flags 0x01 file has a structural .CDX 0x02 file has a Memo field 0x04 file is a database (.DBC) Note that this byte can contain the sum of any of the above values. For example, 0x03 indicates the table has a structural .CDX and a Memo field. 29 Code page mark 30 – 31 Reserved, contains 0x00 32 – n Field subrecords The number of fields determines the number of field subrecords. There is one field subrecord for each field in the table. n+1 Header record terminator (0x0D) n+2 to n+264 A 263-byte range that contains the backlink information (the relative path of an associated database (.DBC)). If the first byte is 0x00 then the file is not associated with a database. Hence, database files themselves always contain 0x00. 1 The data in the data file starts at the position indicated in bytes 8 to 9 of the header record. Data records begin with a delete flag byte. If this byte is an ASCII space (0x20) the record is not deleted; if the first byte is an asterisk (0x2A) the record is deleted. The data from the fields named in the field subrecords follows the delete flag. Field Subrecords Structure Byte offset Description 0 – 10  Field name (maximum of 10 characters; if less than 10, it is padded with null character (0x00)) 11 Field Type: C – Character Y – Currency N – Numeric F – Float D – Date T – DateTime B – Double I – Integer L – Logical M – Memo G – General C – Character (binary) M – Memo (binary) P – Picture 12 – 15 Displacement of field in record 16 Length of field (in bytes) 17 Number of decimal places 18 Field Flags 0x01  System Column (not visible to user) 0x02 Column can store null values 0x04 Binary column (for CHAR and MEMO only) 19 – 32 Reserved For information about limitations on characters per record, maximum fields, and so on, see Visual FoxPro System Capacities. Remarks Visual FoxPro does not modify the header of a file that has been saved to a FoxPro 2.x file format unless one of the following features has been added to the file: • Null value support • DateTime, Currency, and Double data types • CHAR or MEMO field is marked as Binary • A table is added to a database (.DBC) file Tip  You can use the following formula to return the number of fields in a table file: (x – 296/32). In the formula, x is the position of the first record (bytes 8 to 9 in the table header record), 296 is 263 (backlink info) + 1 (header record terminator) + 32 (first field subrecord), and 32 is the length of a field subrecord.

Огромное спасибо. Действительно, со смещением 29 в файлике .dbf указывается кодировка.
Плохо только, что теперь мне придется проверять пред открытием этот самый файлик на указание правильной кодировки, так как при подключении через ODBC нельзя указать (вроде ) ее.
PS: JDBC в этом отношении рулит...

Если кому понадобится, вот процедурка исправления.

Код

bool checkTableCodePage(AnsiString s) { bool changed = false; HANDLE hFile = CreateFile(s.c_str(),GENERIC_READ|GENERIC_WRITE,  FILE_SHARE_READ|FILE_SHARE_WRITE,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,  NULL); if (hFile) {  HANDLE hMapping = CreateFileMapping(hFile,0,PAGE_READWRITE,0,0,0);  // byte with offset 29 from the begining of the .dbf file contains codepage  LPVOID codepageByte = MapViewOfFile(hMapping,FILE_MAP_WRITE,0,0,30);  showError();  // must be 0x65  unsigned char* pch = static_cast<unsigned char*>(codepageByte) + 29;  if (*pch != 0x65) {   *pch = 0x65;   changed = true;  } else {   changed = false;  }  UnmapViewOfFile(codepageByte);  CloseHandle(hMapping);  CloseHandle(hFile); } else {        Application->MessageBox(("Не удается открыть файл " + s).c_str(),"Предупреждение",MB_OK); } return changed; }

Это сообщение отредактировал(а) Hroft - 1.2.2005, 12:00