С новым старым глюком в TPS!

SourceFile              FILE,DRIVER('TOPSPEED'),NAME('calcmemo'),PRE(Source)
KEYI                      KEY(+UNIKNUMBER),PRIMARY,NOCASE,OPT
KEYFORMULA                KEY(+CALCFORMULA),DUP
record                    RECORD
CALCVES                     SHORT
UNIKNUMBER              LONG
CALCFORMULA            STRING(1024) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
CALCRET                    STRING(3)
CALCTYPE                  BYTE
                          END
                        END

Ключ KeyFormula не работает... Т.е. при просмотре по нему не все записи из файла отображаются. Вне зависимости от длины текста в CALCFORMULA

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

SourceFile              FILE,DRIVER('TOPSPEED'),NAME('calcmemo'),PRE(Source)
KEYI                      KEY(+UNIKNUMBER),PRIMARY,NOCASE,OPT
KEYFORMULA                KEY(+CALCFORMULA),DUP
record                    RECORD
CALCVES                     SHORT
UNIKNUMBER              LONG
CALCFORMULA            STRING(512) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
CALCRET                    STRING(3)
CALCTYPE                  BYTE
                          END
                        END

А вот тут уже всё в полном порядке.

kreator

Не работает set/get? Или в шаблонах где-то косяк? В шаблоне "Дерево по одному файлу" был такой косяк.

kreator писал(а): ↑11 Декабрь 2023, 16:51 Не работает set/get? Или в шаблонах где-то косяк? В шаблоне "Дерево по одному файлу" был такой косяк.

Ничего не работает. Даже TopScan сходит с ума при просмотре по ключу.

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

Губин Игорь писал(а): ↑11 Декабрь 2023, 15:20 Ключ KeyFormula не работает...

Никогда не работал. Мы ещё 20 лет назад делали OVER поле для ключа по строкам более 255 символов ...
В драйвере BTRIEVE вообще ВЕСЬ ключ 255 байт и давай до свиданье !

finsoftrz

Игорь Столяров писал(а): ↑11 Декабрь 2023, 17:22
Губин Игорь писал(а): ↑11 Декабрь 2023, 15:20 Ключ KeyFormula не работает...
Никогда не работал. Мы ещё 20 лет назад делали OVER поле для ключа по строкам более 255 символов ...
В драйвере BTRIEVE вообще ВЕСЬ ключ 255 байт и давай до свиданье !

Аналогично.

finsoftrz писал(а): ↑11 Декабрь 2023, 17:39 В драйвере BTRIEVE

TopSpeed:File Maximums/Specifications
File Size : 2 GB
Records per File : Limited to the file size (see below).
Record Size : 15,000 bytes
Field Size : 15,000 bytes
Fields per Record : 15,000
Keys/Indexes per File: 240
Key Size : 15,000 bytes
Memo fields per File: 255
Memo Field Size : 64,000 bytes
BLOB fields per File: 255
BLOB Size : Hardware dependent (Max size 640 MB)
Open Data Files : Operating system dependent
Table Name : 1,000 bytes
Tables per DOS File : Limited only by the maximum DOS file size--approximately 2^32 bytes (4,294,967,296).
Concurrent Users per File: 1024

finsoftrz

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

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

Губин Игорь писал(а): ↑11 Декабрь 2023, 17:46 TopSpeed:File Maximums/Specifications

Контора пишет ! Пойдём логическим путём.
Длина поля в ключе 1KByte. Предположим в списке 100K записей.
Размер ключа будет уже от 100 MByte ... Для ISAM драйвера это пипец.

Игорь Столяров писал(а): ↑11 Декабрь 2023, 18:55 Длина поля в ключе 1KByte. Предположим в списке 100K записей.

Для справки: на момент отлавливания ошибки в файле было 39 (тридцать девять) записей.

С ключами у TPS очень интересная ситуация: они долго и сложно строятся, но, на удивление, очень быстро отрабатывают. У меня есть файлы схожей структуры, но там, при много большем количестве записей, нет таких длинных строк в ключах.

В общем, там, явно, какой-то глюк. Но велосипедистам лучше не сообщать.

Они, пытаясь починить, всё ещё хуже поломают.

kreator

Ну тогда надо науку привлечь. Она сильно не рекомендует индексы (ключи) на строковых полях, особенно на таких длинных. Надо искать другие пути. Губин Игорь, а в чём необходимость такого ключа?

finsoftrz

kreator писал(а): ↑12 Декабрь 2023, 15:22 Ну тогда надо науку привлечь. Она сильно не рекомендует индексы (ключи) на строковых полях, особенно на таких длинных. Надо искать другие пути. Губин Игорь, а в чём необходимость такого ключа?

Какая наука не рекомендует? Длинные строки в ключи засовывать обычно смысла нет, достаточно 10-20 первых символов, чтобы вывести в порядке названий. Отсюда и схема с мач-кодом (over поле над основной строкой). В sql, наверно, такой потребности нет, сервер сортирует выборку динамически, как задано в order by. В tps же иначе как просмотреть записи таблицы в порядке наименований?

kreator

finsoftrz писал(а): ↑12 Декабрь 2023, 15:32 В tps же иначе как просмотреть записи таблицы в порядке наименований?

Во-первых, что Вы гадаете? Может Игорю Губину не это надо. Во-вторых, есть оператор ORDER. Можно без индекса сортирнуть.
А ещё может оказаться, что строковое поле обладает низкой селективностью и поиск (выборка) по индексу более затратна по сравнению с поиском по значениям.

kreator писал(а): ↑12 Декабрь 2023, 15:22 Губин Игорь, а в чём необходимость такого ключа?

В необходимости, минимизировать количество одинаковых записей.

На пальцах:
У меня к каждой записи основной базы есть текстовое примечание, в котором может встречаться масса арифметико-логических условий. Формат примечания произвольный, лишь бы человек понял.

Сейчас пытаемся сделать в программе автоматическое отслеживание этих условий при поиске:

в записи есть поля A < 10, B < 4 и примечание B < A
Сейчас поиск идёт по inrange(a,Amin,Amax), inrange(b,Bmin,Bmax). А надо добавить ещё условие при поиске b < a

Т.е. к каждому текстовому примечанию привязывается набор формул в формате Clarion. Если не дать контроля над дублированием и локатора при поиске, то или база формул начнёт расползаться, что не хорошо по ряду условий, или девочки начнут дёргать каждый раз не найдя при вводе уже готовое решение для привязки к примечанию.

Размер текстового поля для формул закладывается по максимуму. Уже сейчас есть формулы, которые развернуть не хватит и 1024 символов.

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

Губин Игорь писал(а): ↑14 Декабрь 2023, 13:03 Если не дать контроля над дублированием и локатора

Ну локатор с такими длинами - это очень условная вещь ... Вряд ли кто-то будет вводить более 40 символов (OVER !).

А для контроля дубликатов нужно строку нормализовать (убирать пробелы и в один регистр),
потом считать и хранить хеш, и по нему уже строить индекс и проверять дублирование. Вот и всё ...

Игорь Столяров писал(а): ↑14 Декабрь 2023, 13:50 А для контроля

"какой-ты умный, это что-то!"

Ничего личного, так, к слову пришлось. Размер локатора вторичен от размера строки для проверки на дублирование.

Кроме того, выравнивание регистров не всегда допустимо, а удаление пробелов снижает читабельность. Потому и надо гарантировать, что, не заметившая уже введённую формулу, девочка не введёт её ещё раз. И так масса мусора из-за того, что вводят a-b+c < d, c-b+a < d, c-d+a < b...

Хэш это, конечно, хорошо, но он предназначен для того, чтобы сказать "точно не то", а не "точно то". Чисто математически. А срочно, в самый неподходящий момент переделывать всё, если вдруг, получим дублирование хешей не хочется. Система должна работать устойчиво с минимальным вмешательством. Уже сталкивался со сверхсрочной переделкой всего и вся из-за того, что случилось "совершенно невероятное событие".