Добрый день, уважаемые знатоки!
Всех с прошедшим профессиональным праздником!
Помогите пожалуйста разобраться в вопросе.

Я создаю базу для склада инструмента. Она будет разделенной (таблицы отдельно, формы и прочее отдельно). Задался таким вопросом: как сделать так, чтобы при последовательной записи в разные таблицы, в случае непредвиденных ситуаций не произошло так, что в одну таблицу данные записались, в другую - нет. Отсюда мой первый вопрос: 1) Самый простой и правильный выход в данной ситуации использовать транзакции?

Если да, то с ними у меня тоже проблема и отсюда мой второй вопрос 2) Как сделать так, чтобы транзакции нормально проводились? Что я делаю не так?
Дело в том, что при выполнении кода, на строчке с Rollback или CommitTrans вылетает ошибка "попытка занесения или свертывания транзакции без предварительного начала транзакции". Подскажите как сделать так, чтобы все работало )

Прошу больно не пинать за кривой код. Я в этом деле не профессионал, и не все понимаю, что делаю :) Некоторые куски кода просто беру из справки, до конца не осознавая как там что работает. С транзакциями также поступал - брал код из примера support.office, только не работает он у меня.

Привожу кусок кода, повешенный на нажатие кнопки на форме.



На самом деле, таблиц, куда идет запись больше. Просто смысла нет код целиком приводить, я думаю.

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

Да на самом деле база на этапе отладки уже. Формы все сделаны, не хотелось бы менять схему, да и там очень вряд ли можно уйти от записи в несколько таблиц последовательно. Схема довольно сложная. И в некоторых случаях запись приходится через цикл проводить.

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

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

Прикрепляю на всякий случай схему свою.

А что там сложности есть с транзакциями? Я думал, что просто объявляешь транзакцию, делаешь внутри нее записи в разные таблицы, потом эту транзакцию либо откатываешь, либо проводишь. И по CommitTrans все записи одновременно проводятся по всем таблицам. Не так?

Анатолий ( Киев )Попробуйте в разных местах кода повставлять
wrk.CommitTrans
wrk.BeginTrans
Затем выполнить код в пошаговом режиме и определить, где гнилое место.


Да, понял что вызывало ошибку. У меня в коде объявлялся один рекордсет, шло wrk.BeginTrans, и перед wrk.CommitTrans стояло set rs=nothing. Перемещение wrk.BeginTrans до объявления рекордсета или wrk.CommitTrans после set rs=nothing убирает ошибку.

Из моего примера я несколько рекордсетов убрал, в том числе и тот, в котором была проблема, думая, что это только загромоздит пример) Оказалось в нем вся проблема и заключалась)


Анатолий ( Киев )Вообще-то рекомендуется перед стартом ТА рекомендуется проверять Currentdb.Transactions - после старта поднимать флажок - перед применением или откатом проверять фоажок, а после применения сбрасывать.

Что вы имеете ввиду под "поднять флажок"? )

sdkuSergey8969,
хотите или нет но структуру рано или поздно придется переделывать-не буду говорить о всех таблицах-возьмем одну-склад: какие данные и во сколько(ежечасно,ежедневно,чтоб в любой момент времени иметь актуальную инфу)Вы будете заносить в поле "кол-во_склад"-ведь остаток=sum(поступило)-sum(выдано)это вычисляемое поле и ему не место в таблице + создание всего нескольких полей(выдано, поступило,подчинение формы "журналу"в котором отразить кому и когда,на каком основании произведена выдача и т.д) позволит хранить необходимые данные из которых запросами(отчетами) извлекается любая информация-сейчас же Ваши таблицы выполняют функции запросов (вы пытаетесь в таблицах хранить информацию,а не данные,что есть таки, две огромные разницы)

Если я сделаю "кол-во_склад"=sum(поступило)-sum(выдано), то чем дольше живет моя база, тем медленнее она будет работать получается (с каждым днем будет все больше поступило и выдано, которые надо суммировать, причем инструмент каждый день будут выдавать в цех и возвращать назад на склад). Чтобы получить актуальную информацию придется просуммировать все записи начиная от начала работы базы, а их со временем накопится очень много. Разве не так? И разве мой вариант не имеет право на существование? Он позволяет не хранить весь хвост "поступило" и "выдано", а обращаться сразу к актуальной цифре остатка инструмента. Чем это плохо?

Анатолий ( Киев )Sergey8969Что вы имеете ввиду под "поднять флажок"? ) Присвоить True логической переменной или полю.

Анатолий ( Киев )Вообще-то рекомендуется перед стартом ТА рекомендуется проверять Currentdb.Transactions - после старта поднимать флажок - перед применением или откатом проверять фоажок, а после применения сбрасывать.

Пример можно? Не совсем понял вашу мысль. И зачем все это нужно?)
Говорю же - я дилетант в этом деле)

sdkuSergey8969...Если я сделаю "кол-во_склад"=sum(поступило)-sum(выдано), то чем дольше живет моя база, тем медленнее она будет работать... Это не так.Если раз в 2-3 года переносить данные в архив, и записывать остаток в прибыло (с соответствующей отметкой,автоматизировав процесс или вручную) размер БД будет расти очень незначительно, а с 10-30 тысячами записей (наберется за 2 года?) ACCESS справляется "моргнуть не успеете".Проверьте

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

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

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

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


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

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

vmagSergey8969Она будет разделенной (таблицы отдельно, формы и прочее отдельно)

1. Слабо верится в транзакции в таком разрезе, да еще в DAO...
2. Есть куча наработок где за один заход пишется туча всего и во много таблиц, статистика показывает, что если
руки ровные, то транзакции не нужны...
3. Но если очень хочется транзакции, то можно это делать с пониманием происходящего:

Но тогда вопрос - на откат в селекте тоже делать откат ???
4. Схема с хранением количества остатка (особенно если это склад рабочего инструмента, и новые молотки
да отвертки редко докупают и почти не ломают и не воруют) действительно имеет определенный смысл... прихода и расхода практически нет, нужно только знать сколько всего и у кого оно сейчас...
5. Схему бы нужно переделать... sdku не зря подогнал только одну таблицу...
Чего только стоит связка Инструмент 1-----1 Склад.... Типа - каждая отвертка хранится на отдельном персональном складе ???
Что, нельзя было в Инструмент вставить Код склада и количество, чтоб получить естественное Склад 1----- & Инструмент ??? (на одном складе может быть сколько угодно всякого инструмента)

1. А что не так с транзакциями тут? Я пробовал у себя в одной форме - все работало. В остальные пока не внедрял)
2. На счет рук своих я пока не уверен) наработок нет)
3. Думал я тоже такой вариант у себя провернуть, да только у меня там не просто последовательная запись, а условия всякие..) геморно довольно все кейсы прописывать) Если внутри транзакции и так все откатывается по rollback, то так проще гораздо)
4. Это радует)
5. Склад всего один. В этой таблице информация сколько инструмента находится на складе.
Я схему много раз переделывал, и в итоге таблица Склад осталась фактически ненужной - она по сути часть таблицы Инструмент, но я решил оставить ее отдельной таблицей. Не знал как правильнее поступить. На функционал, вроде, не влияет) Чем вообще отличаются 2 таблицы связанные отношением 1 к 1 и просто одна большая таблица??? По сути же одно и то же получается..
Изначально в таблице Склад хранилась информация о количестве инструмента на складе, в цехе и на списание. Идея была в том, чтобы хранить информацию о некоторых свойствах инструмента в таблице Инструмент, а всю количественную информацию хранить в таблице Склад. Я думал, так будет быстрее работать, нежели одна здоровая таблица. Потом мне пришлось для кол-ва в цехе и на списание сделать отдельные таблицы, потому как понадобилось хранить доп информацию у кого какой инструмент находится в цехе, а при отправке на списание - на какой заказ списывается.