forum.clarionlife.net

Привет всем !

Столкнулся с такой задачей: Есть программа (Clarion & ABC) и БД в формате TopSpeed (один список в одном файле).
Для списка есть масса ключей, которые в общем-то сейчас уже не нужны, а программа достаточно сильно
подтормаживает при добавлении данных в этот файл - т.к. происходит перестроение всех ключей в списке.

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

Заранее списибо за любой совет ...

А почему бы для добавления записей не использовать Append,
а BUILD делать иногда по необходимости

lsgsoftware писал(а):А почему бы для добавления записей не использовать Append,
а BUILD делать иногда по необходимости

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

Вообще, конечно идея с ключами внутри файла с данными имеет свои преимущества, но если бы ключи были в внешних файлах - то просто бы удалил их описание в словаре и перегенерил приложение. И отряд бы не заметил потери бойцов ... А так как сейчас постоена структура - при удалении ключей драйвер TPS считает, что было изменение структуры данных (!) и со всеми вытекающими последствиями ...

А в чем разница для append между потоком и формой ?

BOB писал(а):А в чем разница для append между потоком и формой ?

Наверно в том, что для загрузки данных потоком код пишется вручную, а обновления таблиц с помощью FORM генерится на основании шаблонов ABC ...

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

Често говоря - не понимаю почему, имея ПОЛНЫЙ доступ к словарю и возможность самому изменять структуру БД, ты всячески стараешься избежать конвертации нужного файла?! Учитывая, что структура RECORD не изменится - конвертация такого файла будет чисто символической - все записи из старого файла просто будут перелиты в новый без какой-либо обработки!

Олег писал(а):Често говоря - не понимаю почему, имея ПОЛНЫЙ доступ к словарю и возможность самому изменять структуру БД, ты всячески стараешься избежать конвертации нужного файла?!

Очень большое кол-во копий серийной программы и БД (тысячи) находящихся в непредсказуемых и неподконтрольных нам состояних. Операция конвертации (перезаливка файла в новую структуру) - достаточно ответсвенная операция, в которой всегда есть вероятность потери пользователем данных. К сожалению - это подтверждается наличием печального опыта. Да, мы идем на это когда есть очень серьезные причины, и это большая работа (в т.ч. и во времени) свзязанная как с подготовкой таких действия, так и с ее выполнением. В данном случае не нужно менять структуру таблиц - нужно всего лишь убрать ненужные ключи (просто перестали ими пользоваться) из файлов БД. Или хотя бы как-то (?!) выключить их перестроение драйвером БД TopSpeed & Btrieve. Все. Но я прихожу к пониманию, что сделать это невозможно.

Игорь Столяров писал(а):Очень большое кол-во копий серийной программы и БД (тысячи) находящихся в непредсказуемых и неподконтрольных нам состояних. Операция конвертации (перезаливка файла в новую структуру) - достаточно ответсвенная операция, в которой всегда есть вероятность потери пользователем данных. К сожалению - это подтверждается наличием печального опыта. Да, мы идем на это когда есть очень серьезные причины, и это большая работа (в т.ч. и во времени) свзязанная как с подготовкой таких действия, так и с ее выполнением. В данном случае не нужно менять структуру таблиц - нужно всего лишь убрать ненужные ключи (просто перестали ими пользоваться) из файлов БД. Или хотя бы как-то (?!) выключить их перестроение драйвером БД TopSpeed & Btrieve. Все. Но я прихожу к пониманию, что сделать это невозможно.

На счет потери данных при конвертации - неужели кто-то еще запускает конвертор на рабочей и единственной копии БД?!
Я даже для себя делаю конверторы, которые перед конвертацией создают бэкап конвертируемых файлов! Даже простейший стандартный конвертор не замещает и не удаляет старую версию конвертируемой таблицы до последнего момента - пока конвертация не завершится успешно!

А что, ваша БД является пополняемой справочной системой, которая рассылается всем зарегистрированным пользователям?
Даже если так, то не понимаю в чем проблема - ведь все равно рассылается новая копия справочника? Или обновления у вас сделаны не кумулятивными а дополняемыми, сохраняющими все правки пользователей?

А почему не попробовать вот так
В точке Before writing to the disk... вставить
Append
Build на нужные ключи
в рекорд записать кракозябры, чтобы "штатная" ADD не выполнилась( типа дублирования ключа...)
Дальше в точке After writing to the disk... Просто обработать эту ситуацию, чтобы прога не вываливалась
Глядишь и получится

lsgsoftware писал(а):А почему не попробовать вот так...

Если вопрос стоит в том, как подменить оператор ADD на APPEND, то есть много вариантов.
Не знаю как в ABC, но в ШВС с помощью точек вставок можно вообще в форме обойти ADD и написать вместо него свой код.
Еще, как вариант, немного модифицировать шаблоны и вставить код, который позволит легко с помощью глобальной переменной использовать или ADD или APPEND. В ABC подобным образом можно немного модифицировать (заменой или наследованием) нужный метод файлового менеджера.
Ну и, наконец, для ЛЮБЫХ шаблонов универсальный вариант - "навесить" на нужный файл колбэк beforeoperation и подменять операцию ADD на APPEND - опять-же, можно по глобальному переключателю. Только не нужно забывать, что такой колбэк необходимо "вешать" на файл в начале КАЖДОГО треда - лучше всего использовать для этого самописный глобальный тредовый класс, в конструкторе которого и выполнять "навеску" колбэка.

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