MS Access записи в Excel в течение нескольких минут иногда выдает ложную ошибку

Question

Я тот, кто решает проблемы, глядя, а не спрашивая. Так что это ново для меня. Это было проблемой в течение многих лет, и это связано с различными компьютерами, сетями, версиями и совершенно другим кодом. Здесь много всего, поэтому, спасибо заранее, если вы готовы прочитать все это. Вообще говоря, я пишу программы MS Access, которые открывают Excel, а затем создают несколько рабочих листов внутри рабочей книги, используя данные из таблиц Access и / или листов Excel. Процесс может занять несколько минут, а иногда он получит ошибку. Я мог бы сказать вам сообщение об ошибке, но это не имеет значения, потому что оно будет отличаться в зависимости от места возникновения ошибки. Когда это происходит, я просто нажимаю «Отладка» и нажимаю «Продолжить», и это ... продолжается. Если произойдет ошибка снова (много циклов позже), это произойдет в том же месте.

Итак, я начну с незначительных изменений в коде. В текущей программе, над которой я работаю, ошибка возникает, когда я пишу в ячейку, а значение является значением непосредственно из таблицы. Я создал переменную, скопировал значение в переменную и затем записал в ячейку. Ошибка переместилась в совершенно другую часть программы и стала ошибкой «вставки». Как правило, исправление заключается в размещении функции ожидания в месте возникновения ошибки. Одна секунда обычно достаточно хороша. Иногда требуется пара из них, но это обычно решает это. На этот раз потребовалась только одна задержка на цикл, поэтому он работает. Я просто ненавижу вызывать задержки в моей программе. Итак ... Кто-нибудь видел что-нибудь подобное раньше или это только я? Это похоже на проблему синхронизации между Access и Excel, так как задержки обычно полезны. Заранее спасибо.

Answer 1

Я верю, что сейчас это проблема времени. Подумав, я понял, что могу легко (через 3 часа) отделить информацию о базе данных от информации в электронной таблице, а затем переместить обновленный код, вызывающий проблемы, в макрос Excel. Затем я вызвал этот макрос из Access. Ошибки не только исчезают, но и работают примерно в 4 раза быстрее. Это не удивительно, я просто не думал об этом направлении раньше.

Answer 2

Я откопал свой последний крупный проект Access, который взаимодействовал с Word (около 2016 г.), где я боролся с подобными проблемами. Я вижу много-много Debug.Print утверждений (некоторые прокомментированы, некоторые все еще активны), но в отличие от того, что я вспомнил ранее в моих комментариях, я больше не вижу никаких «ожиданий»! Из того, что я сейчас вспоминаю и после повторной проверки кода, большинство проблем было решено с помощью

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

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

---

Вы также никогда не сможете получить хороший ответ на такой вопрос, поэтому, несмотря на это, яЯ не абсолютный эксперт по разработке Office, у меня был собственный опыт с такими ошибками, поэтому я поделюсь своими 2 центами. Это может быть неудовлетворительным, но после того, как я столкнулся с подобным поведением с использованием объектов автоматизации делопроизводства, я понимаю, что взаимодействие между процессами ОС не является детерминированнымТем более, что в VBA обычно нет проблем с многопоточностью или параллелизмом, может быть странно иметь дело с объектами, которые ведут себя непредсказуемым образом. Временные интервалы, предоставляемые каждому процессу отдельно, зависят от операционной системы и будут сильно различаться в зависимости от множества процессоров / ядер, запущенных процессов, управления памятью и т. Д. Несмотря на назначение объектов автоматизации - для управления экземплярами офисных приложений -- API не предназначены для межприкладных процессов.

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

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

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