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

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

CLACOLSEQ работает не на кусок последовательности, он действительно перезатирает прежнюю сортировочную строку.

Нет. В справке сказано немного по другому. Давайте все-таки процитирую:

Кроме значения WINDOWS можно указать строку символов (в двойных кавычках), чтобы прямо определить, какую последовательность сортировки следует использовать. В строку нужно включить только те символы, для которых надо указать новое положение при сортировке. Все остальные, не перечисленные символы остаются на своих прежних местах. Например, если задано CLACOLSEQ='CA'. для стандартной последовательности английского алфавита (ABCD ...), то в результате последовательность станет 'CBAD'.

Все остальные остаются на своих местах. Только не сказано, что перед этим присваиванием, строка сбрасывается в значение
по умолчанию (т.е. ANSI).

[Shur]

Ох, ничего не сбрасывается в ANSI. Просто при сортировке неперечисленные символы остаются на своих местах, потому что ИГНОРИРУЮТСЯ.
Ну я же писал об этом в коде процедуры проверки CLACOLSEQ

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

message(ABCNew&'|'&ABC,'CLACOLSEQ',,,,10b) ! здесь внимательно смотрим: то, что осталось на месте, того вообще, по всей видимости, нет в CLACOLSEQ

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

Ох, ничего не сбрасывается в ANSI.

Спасибо. Вы правы. Указанная Вами комбинация (или аналогичная)

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

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

будет работать на любом компьютере, не зависимо от настроек его локализации. Потому, что по сути, получается, что это ANSI с переопределенной последовательностью сортировки - а она везде одинакова.

Но только внутри Родины. Например, на Украине или Казахстане мы получим проблемы с сортировкой национальных символов.
Значит эти настройки нужно выносить в отдельный файл и настраивать через Locate(ФАЙЛ), с риском, что юзер его может оконфузить.
Альтернатива: Locate('WINDOWS') - тогда все настраивается через параметры локализации Windows, и нет проблем с национальными наборами символов. Но как показал опыт здесь тоже может возникнуть разнобой.
Ситуация прояснилась. Похоже, что 100% satisfaction здесь по сути недостижим, нужно выбирать одно из частных решений.

[Shur]

Наверное можно делать Locate(ФАЙЛ), где будет указан env-файл, находящийся на сервере, доступный только на чтение.
Или скриптом принудительно распространяйте env-файл с сервера на рабочие места перед каждым запуском программы.

[RaFaeL]

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

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

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

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

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

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

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

Здесь важно было понять другое. Есть кодировка ANSI, а есть установленная в Windows национальная.
Можно замещать в ANSI порядок сортировки выбранных символов (как это делаете Вы), либо полностью
устанавливать национальную кодировку Windows: Loсate('Windows') - как это делаем мы.
В Вашем случае будут проблемы с сортировкой национальных символов не русского и латинского алфавитов,
а в нашем зависимость от настройки (и как выяснилось и версии) Windows.

Но к сожалению нельзя сделать mix: переопределить последовательность символов в национальной кодировке
(в т.ч. и непечатной зоны до 31 кода).

[RaFaeL]

В Вашем случае будут проблемы с сортировкой национальных символов не русского и латинского алфавита,

Если кому-то надо будет такое (пока за 15 лет не сталкивались), то поменяет в своей копии программы (т.е. в файле env) эту строчку

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

то поменяет в своей копии программы (т.е. в файле env) эту строчку

Мне надо. Причем уже лет 20. А если я не знаю, в какой стране будет работать программа ?
Это надо либо при установке запрашивать и формировать файл с национальной последовательностью
(Вы знаете киргизский ? Я - нет.) и следить за его наличием и целостностью, либо выпускать отдельно вариант
программы для каждой возможной страны использования. Мрак и жуть.

[RaFaeL]

Кстати вспомнил старую проблему http://forum.clarionlife.net/phpbb/view ... 70&p=15335
Так вот я ее так и не решил, просто перед индексацией прописал LOCALE('CLACOLSEQ','') тогда правильно ключи строит, иначе тоже что-то непонятное

[RaFaeL]

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

Есть третий вариант - в справке (на сайте, в документации, в руководстве по установке) написать - если у вас не русский язык предполагается в базе, зайдите в этот файл и вбейте туда вашу строку сортировки

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

если у вас не русский язык предполагается в базе, зайдите в этот файл и вбейте туда вашу строку сортировки

Ну это вариация формирования файла кодировкой с запросом при установке. Только будет еще хуже.
Я не уверен, что все пользователи в странах СНГ смогут правильно назвать по порядку буквы своего национального
алфавита, даже если смогут или будут читать справку ... Да это и не нужно.
Все уже и так есть в установленной национальной кодировке Windows - можно пользоваться и нет проблем.
Точнее не было, до недавнего времени, пока не появился разнобой в этой кодировке (подозреваю, что после выхода Win10).

[RaFaeL]

Все уже и так есть в установленной национальной кодировке Windows - можно пользоваться и нет проблем.

Она в одной организации может быть разной на двух соседних компах - как ты это решишь?
Так что вынести в файл надежнее с точки зрения последующих возможностей настройки

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

Она в одной организации может быть разной на двух соседних компах - как ты это решишь?

Вот ! Абсолютно верно. Мы и пришли к тому вопросу, с которого я начал эту тему обсуждения.
Наверно, общее решение, может существовать только при переходе на UTF-8 кодировку в БД.

[RaFaeL]

Наверно, общее решение, может существовать только при переходе на UTF-8 кодировку в БД.

Есть другой вариант - переход на SQL, где кодировкой сервер заведует
Вообще, сколько бы меня не убеждали в обратном, то TPS для активной сетевой работы не годится. Проверено десятками клиентов и сотнями, тысячами запусков tpsfix (ну а если терминал, то там проблема с кодировкой тоже исключается).

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

Понятно, что обсуждатся файл-серверная БД, а конкретно TPS.
SQL, терминальный доступ решает многие вопросы (правда требует материальных затрат и квалификации от юзера).
А какая файл-серверная БД годится для активной сетевой работы ?
С натяжкой, к таким можно отнести разве, что Btrieve (не Pervasive.SQL) ....