Access 2010 Macro on Server 2008 R2 Task Scheduler Unattended

Question

Я видел много таких вопросов, но ни одно из предлагаемых решений не работает для меня.

У меня есть макрос Access 2010 под названием «MAIN» (в 32-разрядном Office). База данных содержит связанные таблицы ODBC с различными серверами баз данных и сложные запросы присоединения для сравнения и анализа данных для создания файлов CSV для импорта в стороннюю систему. Макрос предназначен для автоматического запуска этих запросов и сохранения результатов в CSV-файлах для последующего использования сторонним инструментом импорта.

Мое желание состоит в том, чтобы запустить этот макрос «без присмотра», чтобы файлы создавались по установленному расписанию независимо от того, зарегистрирован ли пользователь в системе или нет. В целевой системе работает Server 2008 R2 (изначально 64-разрядная версия Windows).

Многие из ответов, которые я вижу в Интернете, указывают на то, что для макросов Office Automation может потребоваться вход пользователя в систему, чтобы программа Office имела действующий сеанс рабочего стола пользователя. Есть несколько человек, которые дают противоположный ответ: говоря, что может запустить макрос Microsoft Access без использования с помощью Планировщика задач Windows с параметром «Запустить, был ли пользователь включен или нет».

Действие устанавливается в "Запуск программы", с Программой/скрипт установлен в "C: \ Program Files (x86) \ Microsoft Office \ Office14 \ MSACCESS.EXE" и аргументы, изложенные в «C: \ Test_Dir \ Test_DB.accdb»/nostartup/х MAIN

Когда я запускать запланированное задание либо в заданное время или по требованию, он быстро завершает с MSACCESS ResultCode (возвращаемое значение) 2004 года (эквивалент 0x7D4 hex Run Result). Просмотр папки вывода показывает, что файлы не были созданы.

Если, однако, я задал «Параметры безопасности» задачи «Выполнять только при входе пользователя», она успешно выполняется с правильным кодом результата 0 (0x0 hex). Выходные файлы создаются, как ожидалось, в желаемой папке, но это работает только во время входа в систему.

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

Answer 1

Оказалось, что моя проблема связана с тем, что MSACCESS.exe застревает под движком планировщика задач (taskeng.exe) с некоторым неудачным тестовым прогоном и должно иметь диалоговое окно, к которому не подключен экран.

Несмотря на то, что я использовал планировщик задач Windows для «завершения» задачи, процессы MSACCESS.exe и taskeng.exe по-прежнему присутствовали в фоновом режиме, в результате чего мои следующие тесты задачи завершились неудачей, если я не запустил их только как зарегистрированный (тогда они выполняются как стандартный процесс, а не под управлением хоста/задачи задачи).

Мне пришлось использовать диспетчер задач (taskmgr.exe) для отображения процессов от всех пользователей (включая запланированные задачи), сортировки по имени изображения, поиска любых экземпляров «MSACCESS.exe» или «taskeng.exe» и Завершить процесс для каждого.

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

После очистки эти застрявшие процессы вне, задача побежал без присмотра на меня в случае необходимости и с встроенной проверки подлинности Windows (Trusted_Connection), и со стандартом SQL Authen tication username/password для подключения ODBC связанных таблиц.

Я также проверил использование встроенного пользователя «SYSTEM» (NT Authority \ System) в надежде, что задача может выполняться и никогда не требует изменения пароля пользователя, но задача не удалась, и мне пришлось использовать taskmgr.exe снова очистить застрявшие процессы даже после завершения запланированной задачи. Вероятно, это было связано с тем, как я начал эту проблему. У учетной записи SYSTEM должна быть проблема с запуском MSAccess.exe - возможно, появится диалоговое окно, которое я не вижу.

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

Answer 2

Я думаю, что вы неправильно поняли, что «выполняете только», когда пользователь вошел в систему. Это НЕ означает, что вы собираетесь запускать Access без какого-либо «пользователя», но ТОЛЬКО означает, что если человек использует компьютер в это время, THEN запускает задачу.

Ключевой проблемой является то, ЧТО ПОЛЬЗОВАТЕЛЬ зарегистрирован, КОГДА задача должна запускаться?

Другими словами, ВСЕГДА В КАЖДОМ случае будет НЕКОТОРЫЙ пользователь, который вошел в систему для выполнения этой задачи. (опция «запускать только», когда кто-то регистрируется, означает, что если вы выходите из системы и уходите на праздники, то задача не будет выполняться.

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

Итак, в диспетчере задач вы можете выбирать, когда пользователь не вошел в систему, но лучше. ТОГДА, убедитесь, что учетная запись компьютера по умолчанию, используемая диспетчером задач, имеет разрешения для этой базы данных или еще лучше указать учетную запись в планировщике задач.

Я бы хотел, чтобы вы использовали планировщик задач, чтобы УКАЗАТЬ пользователя для запуска задачи - и указать того же самого пользователя, который, как вы знаете, работает.

Answer 3

Я использую 4 Access Database 2010 на сервере Server 2008 R2 с помощью планировщика заданий точно так же, как указано выше, также с теми же настройками. 3 из 4 задач запускаются с результатом 0x0 errorfree, одна из задач заканчивается также ошибкой 2004 года. Кажется, что проблема находится в базе данных. Из-за того, что вся база данных является копией из одной и той же базы данных по умолчанию, единственными разными значениями являются, по меньшей мере, гораздо большее количество наборов записей. Решением может быть выполнение некоторых waitstaits во время экспорта скриптов перед запуском команды application.quit.

Answer 4

Ключевые слова: Remote Terminal (или Citrix). Неразумно, чтобы все пользователи запускали одну и ту же копию проекта MS Access. (.ACCDB или другие варианты) Используйте сценарий, чтобы взять главную копию (или текущую версию) и скопировать ее в папку пользователя. Затем запустите копию в папке пользователя.

Кроме того, вместо ODBC для связанных таблиц.Попросите программистов Access использовать код DSN-Less для установления соединений. Для SQL Server - установите собственный клиент SQL Server 11.0 на сервере удаленного терминала (или Citrix). Сценарий vba может создавать подключения к SQL Server. Это имеет преимущество в работе с AZURE.

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

Answer 5

По моему опыту, проверка «запустить ли пользователь вошел в систему или нет» была на самом деле причиной тех фантомных процессов MSACCESS. Когда он запустится, он попытается запустить Access как некоторый пользователь по умолчанию в фоновом режиме, а затем сбой, оставив процесс запущенным. По-видимому, MSOffice не любит работать не интерактивно.

У меня также (по причинам, которые я еще не определил) возникли проблемы с проверкой поля «работать с наивысшими привилегиями». Я пытался переместить задачу на новый компьютер. Он отлично работал на старом ПК, но на новом я получаю сообщение об ошибке при попытке создать объект Outlook. Я сравнил две задачи и продолжал менять параметры, пока я не сузил их до «запуска с помощью окна с наивысшими привилегиями». Проверено: нет; unchecked: побежал отлично.