forum.clarionlife.net

Привет всем !

Есть ископаемая программа (переделать нельзя) вот с таким списком (формат TPS или Btrieve):

KEY(NUMBER_NAKL)
Record
NUMBER_NAKL Long
CodTovar Long
Price Real
… и т.д.
end

Грубо говоря, это содержание накладных, с единственным ключом по коду накладной. Код товара (CodTovar)- не уникален.
Нужно как-то (!?) однозначно идентифицировать каждую запись в этом списке, что бы привязать к ней другой список …
Такой фокус вообще технологически возможен ?

А записи в этой таблице эта

ископаемая программа

продолжает добавлять и изменять?

SergioRaguzini писал(а): ↑10 Декабрь 2019, 22:27продолжает добавлять и изменять?

Да.

1. Не совсем понятно для чего
2. Непонятно для накладной или для товара
3. И что значит код товара не уникален, под одним кодом может быть несколько товаров?
Можно с помощью - uuid

Можно попробовать pointer или position. Стандартно (для меня) должны быть еще поля идентификатора записи с первичным ключем по нему и номера строки документа (оно же вторым в ключе KEY(NUMBER_NAKL).

Кроме как ввести поле в таблицу вариантов не вижу. А "код товара" и на уровне накладной не уникален?

kreator писал(а): ↑11 Декабрь 2019, 9:40А "код товара" и на уровне накладной не уникален

Неа … В накладной (чеке) могут быть выписаны одинаковые товары. А с учётом того, что теперь маркированные товары
надо пробивать поштучно - это можно даже и не спрашивать … Это старая программа и надо опционально добавить в
неё реализацию новых требований законодательства, желательно не меняя структуру БД …
Будем думать, выход есть всегда … но хотелось бы попроще.

Игорь Столяров писал(а): ↑11 Декабрь 2019, 10:02 Будем думать, выход есть всегда … но хотелось бы попроще.

Мне даже интересно. Поделитесь потом.
Немного оффтоп. Коллеги перенесли на SQL свою базу. Я ещё с ними не работал. А базу вели ещё в ДОСе. Кто когда читает правильные книжки? В общем, много таблиц без первичных и уникальных ключей. И всё, приехали. Завалы разгребали несколько лет. Кларион-то кушает всё. А поведение программы стало непредсказуемым.

Исходники потеряли что ли?

Неа. Исходники как раз-то есть.
Много установленных и работающих копий этой программы, очень не хочется всё это конвертировать в новый формат.

А вы ручками что-ли конвертер пишете?

finsoftrz писал(а): ↑12 Декабрь 2019, 11:18А вы ручками что-ли конвертер пишете?

карандашами

Я бы тоже посмеялся, но дело в том, что уже такие конвертации ископаемых программ проходил.

Это потом будут звонить из деревни в 600 км. от Красноярска, куда вертолёт летает 2 раза в год и
рассказывать, что у них под WinXP заклинило эту конвертацию на 600 мегабайтном файле,
хотя до этого 10 лет всё работало как часы … И спрашивать что делать.

Игорь Столяров писал(а): ↑12 Декабрь 2019, 11:17Много установленных и работающих копий этой программы, очень не хочется всё это конвертировать в новый формат.

А зачем всем конвертировать? Кому надо, тот поставит новую версию и сконвертирует. Остальные пусть на старой работают

Игорь Столяров писал(а): ↑12 Декабрь 2019, 11:32Я бы тоже посмеялся, но дело в том, что уже такие конвертации ископаемых программ проходил.

Это потом будут звонить из деревни в 600 км. от Красноярска, куда вертолёт летает 2 раза в год и
рассказывать, что у них под WinXP заклинило эту конвертацию на 600 мегабайтном файле,
хотя до этого 10 лет всё работало как часы … И спрашивать что делать.

Есть у меня такие, с компьютерами начала века. Копируем весь каталог с программой на более свежий компьютер, конвертим там, возвращаем обратно.
Старость базы у нас не важна. Конвертер генерится автоматически в виде exe на оснований файла версий структур. Который создается с помощью шаблона. Периодически обнуляем файл версий, сохраняя старый на всякий случай. Раз в 2-3 года. Получаем несколько exe. Смотрим дату установленной версии и запускаем последовательно нужные exe.