Неправильно строится ключ файла DBF

[RaFaeL]

Столкнулся с чем-то непонятным: неправильно индексируется файл если указать LOCALE (любую, даже WINDOWS)
Ключ по текстовому полю длиной 4 символа
К примеру записи 04p5, 04p6, 04p7 идут по порядку, а 04p8, 04p9 где-то ближе к концу индексного файла, соответственно SET по значению 04p8 не работает как надо, запись не находит
Версия 6.300.9059
Что делать?

[Shur]

может стоит проверить что в строке: "p" латинская или "р" русская?

[RaFaeL]

Латинская там везде... (или русская везде, не помню)
Таким способом учетка "Парус" кодирует уникальные поля, регистрозависимое 4-х символьное поле, во всех таблицах такое, соответственно для получения данных надо с этими полями работать
Я обошел в итоге эту непонятку, сбросив в пустую строку CLACOLSEQ, после чего стало все работать. Почему же при любой CLACOLSEQ ключ строится неправильно, так и осталось загадкой. Наверное, глюк драйвера

[Ал]

Латинская там везде... (или русская везде, не помню)
Таким способом учетка "Парус" кодирует уникальные поля, регистрозависимое 4-х символьное поле, во всех таблицах такое, соответственно для получения данных надо с этими полями работать
Я обошел в итоге эту непонятку, сбросив в пустую строку CLACOLSEQ, после чего стало все работать. Почему же при любой CLACOLSEQ ключ строится неправильно, так и осталось загадкой. Наверное, глюк драйвера

RBM_K KEY(+GOO:DOCS_RN),DUP ?

[RaFaeL]

Не понял вопроса. Да, этот ключ

[Ал]

Не понял вопроса. Да, этот ключ

у вас в коде

Код: Выделить всё

GOODSPEC             FILE,DRIVER('dBase4'),OEM,NAME('GOODSPEC.DBF'),PRE(GOO),BINDABLE,THREAD
RBM_K                    KEY(GOO:DOCS_RN),DUP
Record                   RECORD,PRE()
DOCS_RN                     STRING(4)
                         END
                     END              

не так стоит - без "+"..., если поставить
RBM_K KEY(+GOO:DOCS_RN),DUP ?

[RaFaeL]

А
Ну вообще говоря это одно и то же. В рабочем проекте с плюсом, никакой разницы

[Ал]

А
Ну вообще говоря это одно и то же. В рабочем проекте с плюсом, никакой разницы

ну ещё и OEM забыт - в рабочем проекте?

[RaFaeL]

Где забыт? Не забыт, на месте

[Ал]

тогда все должно быть отсортировано, если указано RBM_K KEY(+GOO:DOCS_RN) и OEM

[RaFaeL]

тогда все должно быть отсортировано, если указано RBM_K KEY(+GOO:DOCS_RN) и OEM

Если бы это было так, этой темы бы не было ))

[Ал]

Латинская там везде... (или русская везде, не помню)
Таким способом учетка "Парус" кодирует уникальные поля, регистрозависимое 4-х символьное поле, во всех таблицах такое, соответственно для получения данных надо с этими полями работать
Я обошел в итоге эту непонятку, сбросив в пустую строку CLACOLSEQ, после чего стало все работать. Почему же при любой CLACOLSEQ ключ строится неправильно, так и осталось загадкой. Наверное, глюк драйвера

ну я так понимаю так и должно быть - "читать и писать файлы следует, всегда используя одну и ту же последовательность сортировки", а если используется "значение WINDOWS, то последовательность сортировки, используемая по умолчанию, определяется установкой страны в Windows. Если эта переменная в файле установок среды опущена, то по умолчанию используется последовательность сортировки в стандарте ANSI", ну а т.к. стоит OEM - видимо берется набор символов OEM ASCII, в котором и писался файл в Парусе?
Вообщем все как в доке - если файл совместим с DOS, то указываем OEM, в "противном случае задавайте значение WINDOWS или опустите эту переменную".

[Shur]

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

BUILD() как раз и лечит эту проблему. Здесь всё хорошо.

Поиграл с представленной программой. С 04P5, 04P6, 04P7, 04P8, 04P9 проблем с сортировкой не заметил.
Дальше чуть поинтереснее.
1. Если CLACOLSEQ вообще не указан, то берётся сортировка ANSI. Здесь Ал совершенно прав. Заглянем внутрь ndx-файла:

Код: Выделить всё

04P0    pN  04P1    qN  04P2    rN  04P3    sN  04P4    tN  04P5    uN  04P6    vN  04P7    wN  04P7    xN  04P8    yN  04P9    zN  04PA    {N  04PB    |N  04PC    }N  04PD    ~N  04PD    N  04PE    АN  04PF    БN  04PG    ВN  04PH    ГN  04PH    ДN  
...
04PZ    иN  04PZ    йN  04Pa    кN  04Pb    лN  04Pc    мN  04Pd    нN  04Pe    оN  04Pf    пN  04Pg    ░N

Теперь посмотрим, если CLACOLSEQ=Windows. Фрагмент ndx-файла:

Код: Выделить всё

04P0    pN  04P1    qN  04P2    rN  04P3    sN  04P4    tN  04P5    uN  04P6    vN  04P7    wN  04P7    xN  04P8    yN  04P9    ©N  04Pa    zN  04PA    ЄN  04Pb    {N  04PB    «N  04Pc    |N  04PC    ¬N  04Pd    }N  04PD    ~N  04PD    ­N  04Pe    N  04PE    ®N  04Pf    ЂN  04PF    ЇN  04Pg    ЃN  04PG    °N  04Ph    ‚N  04PH    ѓN  04PH    ±N  

Обращаем внимание, что 04Pa стоит раньше 04PA, а 04Ph стоит раньше двух 04PH.

Наконец рассмотрим CLACOLSEQ='AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuWwXxYyZzАаБбВвГгДдЕеЁёЖжЭзИиЙйКкЛлМмНнОоПпРрСсТтУуФфХхЦцЧчШшЩщЪъЫыЬьЭэЮюЯя'.

Код: Выделить всё

04P0    pN  04P1    qN  04P2    rN  04P3    sN  04P4    tN  04P5    uN  04P6    vN  04P7    wN  04P7    xN  04P8    yN  04P9    zN  04PA    *       ©N  04Pa    {N  04PB    ЄN  04Pb    |N  04PC    «N  04Pc    }N  04PD    ~N  04PD    ¬N  04Pd    N  04PE    ­N  04Pe    ЂN  04PF    ®N  04Pf    ЃN  04PG    ЇN  04Pg    ‚N  04PH    ѓN  04PH    °N  04Ph    „N  

На мой взгляд из представленных этот вариант наиболее приемлем: сначала идёт 04PA, потом 04Pa; сначала два 04PH, потом 04Ph.

Как-то так.

[Ал]

...Как-то так.

ого, целое исследование!
для каких версий операционных систем Windows и с какими региональными установками проверялось?

PS TC, по-моему, написал, что не сработал у него BUILD - при принудительной смене последовательности сортировки/кодировки в индексном файле строится последовательность отличная от исходной (т.е. при которой создавался файл с данными в Парусе)

неправильно индексируется файл если указать LOCALE (любую, даже WINDOWS)

, пока он не сбросит настройки

Я обошел в итоге эту непонятку, сбросив в пустую строку CLACOLSEQ, после чего стало все работать. Почему же при любой CLACOLSEQ ключ строится неправильно, так и осталось загадкой.

[Shur]

для каких версий операционных систем Windows и с какими региональными установками проверялось?

Ценное замечание. Тесты проводились под Win10, локализованной для русского языка.

PS TC, по-моему, написал, что не сработал у него BUILD - при принудительной смене последовательности сортировки/кодировки в индексном файле строится последовательность отличная от исходной (т.е. при которой создавался файл с данными в Парусе)

Созданный в чём угодно DBF файл при перестроении индексов не трогается. Пересоздаются только индексы. И никого не волнует с каким CLACOLSEQ и с какой локализацией создавался файл данных.
Последовательность в индексном файле, естественно, зависит от CLACOLSEQ, чему и был посвящён мой предыдущий пост.