v7: Как определить, активна ли транзакция #565268

Собственно, сабж. База DBF. И вообще, если Док.Провести возвращает нуль, транзакция остается активной?

а про какую транзакцию речь? автоматическую при проведении документа или пользовательскую НачатьТранзакцию?

нет

а не типовых способов нету случаем? Скажем, у FormEx или 1C++ ничего такого не наблюдалось? Вроде бы в доках рылся внимательно, но мало ли что.

проблемку полностью опиши - может чего дельного и насоветуем...

Ищу адекватный способ разбить большую транзакцию на ряд более мелких: проводится достаточно большой пак документов, при возможных ошибках неохота перепроводить все с самого начала. Нарисовал так: и основная процедура выглядит так Из приведенного кода выкинул для краткости всякие "сообщить" и прочую обвеску. Так вот, на ЗафиксироватьТранзакцию в функции СчетчикПлюс оно падает с воплем "Транзакция не активна". Причем в первом же паке, когда счетчик до 10 доезжает.

+ это "грубо"... а вообще фиксируй/отменяй транзакцию в самом цикле, а не в функциях

Вот самый простой пример НачатьТранзакцию;

так делать категорически не верно. Будет полная каша в проводках/движениях регистра. Так что, весь код в топку смело.

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

не вижу разницы от исходного варианта, ведь если что не так - до СчетчикПлюс все равно не докатится - на Возврат наступит. хотелось избавиться от проверки счетчика, общая обработка достаточно сложна. А в чем грубость в выносе повторяющегося кода в отдельную функцию? Док.Провести может трапнуться, и его палюбасу нужно в Попытку оборачивать. Тоже повод для выноса кода в отдельную функцию. А как верно? Вообще от транзакций отказаться? А как работает штатное восстановление границы последовательности?

Которое в меню Операции ? Там ТА сдвигается назад и всё проведение в потоке идёт.

+12 каждый док толкает ТА вперёд.

Но ведь согласись, что при восстановлении ГП в базу запись изменений проходит не сразу, нечто вроде транзакций используется. Иначе оно б не выполнялось с такой скоростью. Опять-таки, я там не слишком вкурил, в каком порядке штатное восстановление ГП документы выбирает для проведения, оно нифига не согласуется с позицией документа. А вот сейчас проверю.

а если в модуле проведения отстатки тянутся прямым запросом - тоже такой глюк?

рапортует    Получено движение Заявка покупателя 0000000292 (21.02.07)    Движений нет - тест выборки в транзакции успешен что я не так делаю?

кешируются некоторые данные. Но не всё.

Что-то ты путаешь. Сделал эксперимент: На складе есть 50 шт товара. Делаю два не проведенных расходных документа по 30 шт, провожу их в одной транзакции и на втором документе срабатывает контроль остатков. ЧЯДНТ?

Лень проверять, но транзакция - зло.

Классный аргумент, позитивный. Даже настроение поднялось. И черт с ней, с производительностью. Согласен.

Какая в п..ду производительность при коде в ? Ты вообще о чем ?

Быстрее чем через меню операции  - не сделаешь, у тебя всегда проведение задним числом при коде в , ===> всегда временный расчет регистров, заместо того, чтоб сразу брать актуальные итоги.

Окей, пусть там криво и вообще неправильно. Как правильно и быстро перепровести пакет документов при том, что все перепроводить не нужно, а лишь часть? Например: в сегодняшнем конкретном случае требовалось в ТиС перепровести все заявки на склад, по которым были остатки по регистру резервов. Сделал, отказавшись от транзакций, но интерес к теме есть и на будущее. Расставить документы по дате, и перед проведением каждого документа гонять ТА?

создать нужную последовательность, перепровести её

да все правильно. так и надо перепроводить небольшими транзакциями. Просто ты где-то что-то напутал в коде. Упрости код до и проверь

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