Добрый вечер

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

Нужно встроится в эту тему, со своей выгрузкой.
Не обсуждая, что сделано это через ж, мне конкретно нужно организовать эти два действия в транзакции.

ВОПРОС:
Как реализовать в одной транзакции (или ее подобии) такие действия как запись в файл и запись в объект 1с ?

Если понимать под транзакцией то, что об этом думают нормаьные люди, то нет.

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

(2) "Запись в файл никогда не идёт в транзакции"
Вот сейчас разработчики ntfs и ext3/4 поперхнулись и чуть не подавились...

Отличные советы
Только мне нужно вопрос решить)

(4) Осталось понять, что же тебе по факту нужно...

(5) нужно то, что дает транзакция, а именно уверенность, что:
- если есть файл, значит флажки проставлены
- если флажки проставлены, значит файл был создан

(6) ТОгда нет.

(6) а альтернативный способ решения?

(6) все равно ведь файл доступен из windows. Файл удалят, а флажок останется.

(8) например? чтобы очень аналогичный
кстати, попутно возник вопрос, как это 1с реализовала в плане обмена

(6) а что мешает сканированть раз в минуту каталог с файлом и поднимать флажок ?

(9) теоритически да, но есть логи +файл дублируется в архив

(12) тогда уж файлы хранить в базе и не париться.

(11) не, нужно разово все сделать
файл потом пойдет дальше по процессу

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

(14) не верная постановка задача, нужно пройти по цепочке дальше

(16) мастерски в нужное русло....

(15) замутить РС это более верно, но пока в существующих рамках пробую сделать

пока такая видится картинка приближенная:

НачатьТранзакцию

ЗаписьДокументов()

Если Файл.Записать() Тогда ЗафиксироватьТранзакцию Иначе ОтменитьТранзакцию()

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

(20) мысль интересная

(21) Просто я так всегда делаю - файл создаётся со временным именем, а когда он уже готов - помещается на правильное место.
При этом, если файл с данными, то до момента замены может существовать прошлый файл - и нет момента, когда файл не записан до конца.

(22) "помещается на правильное место" - вот это не очень нравится
была такая мысль, но переименование видится надежнее

(22) (23) Переименование надёжней, когда оно файлово атомарно... Но не всегда такое возможно.

(23) У меня сначала удаляется временный файл с префиксом .old, его содержимое или на ветер или в {Number}.history, потом основной файл переименовывается в .old, а файл .new переименовывается в основной.
P.S. в пределах диска перемещение и переименование файла - одинаковые операции и не приводят к копированию или перемещению данных файла.

P.S. просто я писал базу на текстовых файлах - поэтому вопрос "обновления" данных с сохранением "полной" версии файла был очень важен.

(25) в моем случае дело будет происходить в кластере
и имя временного файла нужно будет делать средствами 1с
поэтому неизвестно на каком именно диске он появится

(25) В пределах логического тома, извините...

(28) Ну да - логический диск - это и есть том.

(27) Ну директория-то, в которой он должен появиться - известна ?

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

(29) Диск != том %-))

(31) слог неосилил)

(32) То, что в Windows-е называется диском - это именно том, хотя, можно подмонтировать другой диск, как папку.

(30) в целевом каталоге уже есть регламентированная структура, но этот момент тоже рассмотрю

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

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

(37) и при записи на диск ты имеешь фейл. А если понадеешься на атомарность - то ещё и эпический...

(24)
> Переименование надёжней, когда оно файлово атомарно.
т.е. переименование может быть выполнено частично?

(39) Да.
если идёт move d:\file.txt z:\file.txt
где z - сетевой диск

(40) не, я противопоставлял переименование перемещению
что переименование надежнее

покритикуйте, чем плох вариант в (19)

(41) К сожалению, в системе нет отдельно переименования и отдельно перемещения - команда одна - поэтому, результат может быть странным.
Кроме того, в новом месте появляется файл, а он ещё не до записан - и всё, кто-то "съел" и "подавился".
(42) Ну, вполне себе терпимое решение.
Просто, если хочется сообщать о том, что файл уехал, и очищать ссылки на записанное в файл, то это лучше делать тогда, когда с той стороны получили ответ, что данные были получены.

(43) я так понимаю, что косяки переименования могут быть если не ntfs или тому подобное нетранзакционное

(43) ну это да, как работает план обмена
в простом варианте на нем и нужно делать

(44) Если не в пределах одной папки - то независимо от системы. Если в одной папке, то только при отключении питания в момент записи.
Вообще-то, файл будут доставлять и читать - где гарантия, что он прочитается ?
Поэтому, лучше как в нормальном обмене - отправку подтверждать или для всех данных в пакете (как сделано в 1С) или по каждому объекту (если что-то могло не дойти).

(45) Просто - боязнь, что файл не запишется, это не самое страшное - прекрасно записанный файл может не читаться на той стороне из-за того, что формат файла не совместим с базой.
(Например - в файле элемент, а в базе - группа).

(46) опять же, я не говорю про перемещение

(47) замечание хорошее, но в существующей дорабатываемой схеме не вариант сейчас перепиливать

(0) wiki:ACID

(13) обмен между разными базами

(38) Ну транзакция может приводить и к фэйлу