Не страшно ли временные таблицы временно сделать постоянными?

[Gustav]

Уважаемые коллеги, нуждаюсь в вашей оценке ситуации.

Мне нужно быстро получить данные из некоторой формы, в которой есть два грида: главный и подчиненный.
Гриды основаны на временных таблицах.
Получить нужно содержание этих двух таблиц, чтобы потом поанализировать эти данные вне Аксапты (в Аксесе).
Если бы таблица была одна, то проблем бы не было: Ctrl+C, Ctrl+V - и все дела.
Но их две и они связанные. И копировать порции данных из подчиненной таблицы, перемещая курсор в главной - нереально.
Программировать ничего не хочется (в силу цейтнота и недостаточного пока навыка делать это в Аксапте с приемлемой скоростью).

Я попробовал на тестовой базе следующее (и вроде получается):
1. Предупредил юзеров, чтобы они не запускали аналогичный расчет на других компах.
2. Прописал в репозитарии этим двум таблицам свойство Temporary = No.
3. Запустил расчет кнопкой на форме.
4. По окончании расчета сохранил данные из этих таблиц вне Аксапты (средствами Oracle).
5. Вернул в репозитарии этим двум таблицам свойство Temporary = Yes.
6. Разрешил юзерам снова пользоваться этим расчетом со своих машин.

ВОПРОСЫ:
Можно ли поступать подобным "пиратским" образом в "экстремальной" ситуации?
Нет ли здесь каких-нибудь подводных камней?
Может быть, надо провести еще какие-то подготовительно-заключительные мероприятия (какие-нибудь переиндексации, перекомпиляции и т.п.) ?

P.S. Чтобы не быть голословным, скажу, что речь идет о:
"Расчеты с поставщиками -> Периодические операции -> Книга покупок -> Обработка входящего НДС".
Таблицы: TmpPurchBookVATProcessLogTransOper_RU и TmpPurchBookVATProcessLogTrans_RU

Заранее благодарю.

[macklakov]

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

[macklakov]

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

[raz]

Можно вместо предупреждения юзеров, в init()сделать проверку на curuserid(), если тот который надо, то продолжить, для остальных сообщение о временной неработоспособности формы.

[macklakov]

Цитата:

Сообщение от raz

Можно вместо предупреждения юзеров, в init()сделать проверку на curuserid(), если тот который надо, то продолжить, для остальных сообщение о временной неработоспособности формы.

а если он 2 раза форму откроет? Только не спрашивай, зачем
P.S. В таком случае, нужно кроме проверки, добавить чистку таблиц, при закрытии формы. Что делает объем доработок бОльшим, чем рисование грида, с нужными данными

[Wamr]

может для экстренных случаев, скопировать форму, в которой просто разорвать связь мастер-детаил?

[mit]

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

[Gustav]

Цитата:

Сообщение от macklakov

попробуйте...выгрузить их с помощью автоотчета в текстовый файл

С автоотчетом мне идея нравится, только это... как бы еще из подчиненного грида при этом выгрузить содержимое всей таблицы, а не только той порции, которая на экране в текущий момент? (может, есть какая-нить "галка", разрывающая связь гридов, хотя бы временно?)

P.S. Похоже, я долго думал над этим своим ответом...

[mit]

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

[Gustav]

Ну, что, коллеги, всем – спасибо, респект и уважуха!

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

Выбран вариант с автоотчетами (с выводом в файл) и с временным разрывом связи между таблицами на форме.

Изменения нужно будет внести в две таблицы и в одну форму. Табличные модификации возвращать в исходное состояние потом необязательно, а вот форму по окончании всего нашего процесса необходимо будет восстановить.

Итак, по шагам (для благодарных потомков):

Вначале разбираемся с полями автоотчетов: мы хотим, чтобы в файл вывелись значения всех полей каждой таблицы, поэтому необходимо поместить в группу полей AutoReport каждой таблицы все ее поля (точнее, вначале проверить и если это не так, то подкорректировать).

1. Выбираем в репозитарии первую (главную) таблицу TmpPurchBookVATProcessLogTrans_RU, т.е. AOT -> Data Dictionary -> Tables -> TmpPurchBookVATProcessLogTrans_RU.
2. В узле этой таблицы раскрываем узел //Field Groups/AutoReport.
3. Удаляем все поля из списка полей AutoReport: выделяем все поля в списке (кликаем на первом поле, потом - с Shift на последнем), далее правокликаем на этом выделении и выбираем "Удалить из проекта".
4. Помещаем заново все поля таблицы из узла //Fields в узел //Field Groups/AutoReport: выделяем все поля и копируем перетаскиванием.

Реорганизуем вновь созданный список полей так, чтобы связующие поля были самыми первыми (или самыми последними). Это исключительно для удобства последующей обработки данных, чтобы не искать эти ключевые поля среди множества других в будущем файле. Из узла //Relations второй (ПОДЧИНЕННОЙ) таблицы TmpPurchBookVATProcessLogTransOper_RU нам становится ясно, что наши таблицы связаны следующим образом по двум полям:
подчиненная.LogTableRefRecId == главная.LogTableRefRecId
подчиненная.RefRecId == главная.BatchRecId

5. Поскольку мы сейчас оформляем главную таблицу, то находим в ее списке полей узла //Field Groups/AutoReport поля LogTableRefRecId и BatchRecId и при помощи клавиш Alt+СтрелкаВверх и Alt+СтрелкаВниз выводим эти поля соответственно на первое и второе место сверху.
6. Сохраняем первую (главную) таблицу TmpPurchBookVATProcessLogTrans_RU
7. Проводим аналогичные манипуляции со второй (подчиненной) таблицей TmpPurchBookVATProcessLogTransOper_RU (уф! какие же длинные названия... где ты, dBase III, c твоими 10-тисимвольными именами? )

С таблицами двумя разобрались. Переходим к форме "Книга покупок (Обработка входящего НДС)": делаем ее резервную копию (на всякий пожарный), после чего временно курочим основной экземпляр.

8. Нашли форму: AOT -> Forms -> PurchBookProcessVAT_RU (репозитарное имя формы нам известно ранее из правоклика на ней в пользовательском интерфейсе и последующей "Настройки").
9. Создали копию: правоклик -> Дублировать. Создалась форма c именем "CopyOf<имя нашей формы>".
10. Вернулись к узлу основного экземпляра (который без префикса "CopyOf") и открыли узел //Data Sources/<узел ПОДЧИНЕННОЙ таблицы>.
11. Стоя на датасорсе подчиненной таблицы открыли "Свойства" (по Alt+Enter или по правоклик -> Свойства).
12. Стерли значение в свойстве JoinSource, тем самым разорвав связь между таблицами на форме. Перед стрианием в этом свойстве было прописано имя ГЛАВНОГО датасорса, которое, кстати, может отличаться от имени главной таблицы, которая этому датасорсу соответствует! - но не переживайте, у нас есть копия формы, в которую мы всегда сможем при необходимости заглянуть, чтобы в будущем правильно восстановить измененное свойство).
13. Сохраняем измененную форму (т.е. основной экземляр).

Подготовительные мероприятия закончены. Покидаем репозитарий, идём запускать расчетный процесс: "Расчеты с поставщиками -> Периодические операции -> Книга покупок -> Обработка входящего НДС -> кнопка "Выбрать" -> задаем параметры -> OK. Дожидаемся окончания процесса расчета и переходим к выводу данных в текстовый файл.

Форму "Книга покупок (Обработка входящего НДС)" пока ни в коем случае не закрываем, иначе расчет придется запускать заново!

14. Встаем на верхнюю (главную) таблицу формы и далее: Файл -> Печать -> Выберите отчет: Автоотчет -> кнопка "Опции" -> Канал вывода: Файл -> Формат вывода: ASCII -> Имя файла: задаем -> OK. Данные главной таблицы выводятся в текстовый файл.
15. Встаем на нижнюю (подчиненную) таблицу формы и повторяем операции по аналогии, задав другое (отличное от первого) имя файла. Данные подчиненной таблицы выводятся во второй текстовый файл.

Цель достигнута - данные для последующего анализа вне Аксапты получены. Переходим к заключительным мероприятиям.

16. Возвращаемся в репозитарий и находим нашу форму PurchBookProcessVAT_RU.
17. Восстанавливаем значение свойства JoinSource в подчиненном датасорсе, при необходимости подсмотрев его значение в копии формы "CopyOf...".
18. Сохраняем форму.
19. Удаляем из репозитария копию формы c именем "CopyOf<имя нашей формы>" (убедившись, что она нам больше не нужна, например, для каких-то других экспериментов).
20. Говорим: "Спасибо, Аксапта!" и переключаемся на свои драгоценные текстовые файлы.

[mit]

1)так как "Обработка входящего НДС" происходит периодически, можно "CopyOf<имя нашей формы>" не удалять, а отредактировать (разорвать джойн) и работать с ней в дальнейшем(даже вывести в меню повесив какой нибудь ключ от любопытных пользователей, для избежания вопросов "а что это такое?").
2)так как мы можем получить данные из автоотчета целиком для обеих таблиц делать таблицы невременными смысла видимо нет.
3) если в форме, изменения на Вашем слое только разрыв джойна - то резервную копию можно не делать. если Вы хотите вернуться к базовой версии формы, достаточно просто удалить ее из текущего слоя.

[Gustav]

Цитата:

Сообщение от mit

2)так как мы можем получить данные из автоотчета целиком для обеих таблиц делать таблицы невременными смысла видимо нет.

Да, безусловно. Спасибо за акцент.
Для расписанного подробного алгоритма - смысла нет.

Т.е. есть у нас получилось в итоге два альтернативных алгоритма:
ЛИБО с временной "постоянностью" временных таблиц (это то, с чего мы начали),
ЛИБО с автоотчетами (это то, что получилось потом).

Оба имеют право на существование (со всеми оговорками нашей дискуссии).
Лично мне больше нравится второй (хоть в нем и больше операций).