|
![]() |
#1 |
Участник
|
Кстати, все описанные варианты не взаимоисключающие, а, скорее, взаимодополняющие
1. Перемещение файла упростит анализ того, что вообще надо обрабатывать, а что уже обработано. Все, что в указанной папке - надо обработать. После обработки файл в другой папке 2. Дополнительная таблица - это лог того, что обработали. Удобно для "разбора полетов" в случае каких-то проблем 3. Блокировка по sp_getapplock - ну, это гарантия того, что 2 пользователя не попытаются "одновременно" взять (переместить) файл
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
![]() |
#2 |
Участник
|
Добрый вечер.
Смотреть на флаг read-only у целевого файла - стандартный способ для встроенной системы контроля версий в Аксапту. Однако общепринятой практикой является таблица с логическими флагами или статусами. Самым простым выглядит, для пользовательского процесса, запускать всё тоже пакетное задание, но в синхронном режиме, с ограничением (batch constrain) на выполнение иного пакетного задания. Тут всё зависит от контекста. Зачем вообще пользователя подпускать к данному процессу? Он системе как-то помогает? Да вряд ли... Приоритизирует файлы к обработке потому что эти данные нужны здесь и сейчас? |
|
![]() |
#3 |
Участник
|
Цитата:
Батч будет каждую неделю. Пользователи будут корректировать файлы, что не импортировались вследствие ошибок в данных, и тут же ре-импортировать Последний раз редактировалось Lankey; 13.06.2024 в 08:29. |
|
![]() |
#4 |
Участник
|
Спасибо. Синхнонное выполнение батча - интересная идея, но, мне кажется, редко используется. Почему? Тк ошибки пользователю не показываются в таком режиме. то есть, менее user-friendly, чем интеррактивный режим? Или есть какие-то еще подводные камни?
|
|
![]() |
#5 |
Участник
|
Цитата:
После обработки он будет в другой папке. Я тут писала про "промежуточную папку" (как axm2017 описывает выше) , где файл будет, пока не закончена его обработка. Можно, действительно, без нее: если процесс прервался с ошибкой по какой-то причине перемещать его обратно папку-источник в catch блоке. Хотя, если вообще прервана связь с сервером, это не поможет. Последний раз редактировалось Lankey; 13.06.2024 в 08:33. |
|
![]() |
#6 |
Участник
|
Поясните, пожалуйста, зачем (3), если сделать (2), то есть, уже по таблице,вроде, можно понять, заблокирован файл или нет.
|
|
![]() |
#7 |
Участник
|
Цитата:
1. Первый пользователь выбрал файл 2. Второй пользователь выбрал файл 3. Первый пользователь сделал запись в лог 4. Что помешает второму пользователю также сделать запись в лог? Т.е. просто будут 2 записи в логе и 2 пользователя "одновременно" попытаются обработать файл В случае же блокировки ресурса, первое, что делает пользователь после выбора - пытается заблокировать ресурс. Удалось? Можешь продолжать. Нет? Этот файл взял другой пользователь
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
![]() |
#8 |
Участник
|
Цитата:
То есть, такой лог , в моем понимании, альтернативен Вашему предложению использовать sp_getapplock . Только лог дополнительно полезен тем, что потом можно его анализировать потом, а sp_getapplock - нет Последний раз редактировалось Lankey; 13.06.2024 в 17:53. |
|
![]() |
#9 |
Участник
|
Цитата:
1. Первый пользователь ищет запись. Не нашел 2. Второй пользователь ищет запись. Не нашел 3. Первый пользователь создает запись 4. Второй пользователь создает запись Уникальный индекс по имени файла? А если в разное время приходили файлы с одинаковым именем? По каким критериям выполнять поиск? Вы не контролируете то, что получаете из-вне системы. Статусы могут контролировать только записи таблицы. Но что именно записано в эти таблицы? При работе с данными, которые приходят из вне системы, использование таблицы блокировок для контроля - крайне не надежный инструмент.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
Теги |
ax2009 |
|
|