Проблема с кодировкой TPS

[Shur]

У нас вот такая строка в файле env:

Да, это уже понятно. Здесь могут быть вариации. Ваш пример, на мой взгляд, удачней приведенных ранее.Потому что, например, в списке имен "анна", будет идти сразу за "Алина", а не за "Яна".

Мой совет, делайте сортировку по символьным полям case insensitive. А то наслушаетесь разных дядек и получится у вас, что:
1. Анна
2. алина

Если вы прислушаетесь к этому простому совету, то вам уже будет всё равно какой именно CLACOLSEQ будет в env-файле:

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

CLACOLSEQ=" !""#$%&''()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюя"

или

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

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

P.S. Впрочем в последнем я не уверен, что будут правильно сортироваться цифирьки.

[Игорь Столяров]

делайте сортировку по символьным полям case insensitive

Не дай бог, кому-то давать советы, тут бы самому разобраться.
Можно для меня пояснить: Вы имеете ввиду, что нужно строить ключи и индексы по символьным полям с опцией NOCASE ?
И как это все "всё равно какой именно CLACOLSEQ" скажется на сортировку QUEUE ?
Например есть LIST с сортировкой записей по символьному ключу с опцией NOCASE.
Я сортирую записи в этом списке, щелчком мышки по шапке этого же поля. И что я получу в этом случае ?

[Shur]

И как это все "всё равно какой именно CLACOLSEQ" скажется на сортировку QUEUE ?

Я так всегда делаю...

Q queue
f1 string(32)
f1uppercase string(32) ! сюда постоянно записывается результат upper(f1)
end
...
sort(Q,+q.f1uppercase)
...

P.S. Сейчас уже можно прикрутить специальную функцию, конечно. Но раньше... только так.

[Игорь Столяров]

Я так всегда делаю...

Предупреждать надо. Я же не знал, что Вы создаете отдельно дубликат символьного поля для сортировки.
Но беда в другом. Шаблон сортировки записей в LIST про такую хитрую штуку не в теме.
И получится что сортировка записей по ключу с наименованием - это одно, а сортировка записей по колонке
с этим же наименованием (QUEUE) - совсем другое. А в остальном да, нет значения какой задан CLACOLSEQ ...

[dsabitov]

Добавлю пару мыслей от себя.
По моему мнению не стоит пользоваться опцией NOCASE. Тогда вы всегда будете "в более общей теме". Мы же данные учитываем - двусмысленности нам совсем не нужны. Как пример - не так давно настраивал папку для сетевого сканирования. Потерял почти целый день и кучу нервов. Потому что на сетевом хранилище обозвал папку \\Scanners\Xerox WC7530, а в настройках самого устройства путь прописал \\scanners\xerox wc7530. Просто сетевое хранилище крутится на UNIX - ему совсем не все равно какими буквами прописан путь.
Второй момент - какой вариант CLACOLSEQ использовать? Тут нужно спросить себя - какую сортировку данных ожидает пользователь? А пользователь наш очень любит продукты MS, например excel. В excel (так сортирует excel на компьютере со стандартно установленной ОС Windows - без всякого колдовства) данные сортируются следующим образом (левая колонка до, правая - после сортировки):

Значит, правильно будет использовать именно строку:

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

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

[Игорь Столяров]

Тут нужно спросить себя - какую сортировку данных ожидает пользователь? А пользователь наш очень любит продукты MS, например excel. В excel (так сортирует excel на компьютере со стандартно установленной ОС Windows - без всякого колдовства) данные сортируются следующим образом

К сожалению - это не совсем так. Вы пропустили первые 120 серий нашего сериала, мы это обсуждали.

Продукты MS (и Excel в частности) и используют ту последовательность сортировки, что прописана в региональных настройках.
Беда в том, что конкретно файлы TPS (творение SV) сохраняют в себе ту последовательность, с которой они созданы
(или были потом перестроены индексы Build / Pack). Последовательность в региональных настройках может быть любая, проблема
в том, что если она не совпадает с той, что записана в шапке TPS - то начинаются проблемы с доступам к данным по символьным
ключам / индексам. Установка CLACOLSEQ - не решаем проблему, т.к. меняет только печатную часть таблицы сортировки.
И это только проблема формата TPS с его долбаной структурой. Например, тот же BTRIEVE просто использует установки Windows,
но не хранит их внутри файлов данных. Да, при ее изменении нарушается порядок сортировки записей по ключам.
Но ошибок доступа к данным не возникает. Это проверено.

[dsabitov]

Это очень печальное обстоятельство. Значит установка в приложении

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

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

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

[Игорь Столяров]

А ведь TopSpeed не зря так назвался - реально быстро работает.

Великолепный драйвер. Как бы объяснить ... У белых людей, которые его создавали, одна раскладка клавиатуры.
И им пофиг все эти проблемы. Отказываться не надо, к тому же проблема проявляется только при одновременной
работе с общей БД из разных ПОКОЛЕНИЙ Windows (здесь спасибо Microsoft).
Просто надо знать, что проблема имеет место быть.
Формат TPS есть, такой как он есть. Может еще какой-то формат БД хранит в каждом файле последовательность
сортировки в национальной кодировке, но момент создания ... но я такого не видел (не путать с кодировкой БД).