У нас возникла любопытная проблема с нашим автоматическим процессом обновления в Excel (более 50 раз в день), который работал гладко в течение многих лет и был способен выдержать уже 2 обновления Office в прошлом (с 2010 года с 32-разрядной до 64-разрядной, а затем и до 2013 г. 64) битовая версия). Недавно мы были вынуждены перейти на новый Office 365. Начались наши проблемы.
Файлы Excel плавно обновлялись с помощью этой автоматизации, а затем неожиданно через 8-24 часа процесс отказывался от продолжения. Мы получили общее сообщение об ошибке: Вы не можете вызвать метод для выражения с нулевым значением. Как что-то внезапно потеряло права на выполнение для какого-либо объекта.
Ошибка не связана с учетной записью (которая ее запускает), не связана с файлом Excel, который впервые получил ошибку. Как только мы получим эту ошибку в первый раз, файл NON из excel больше не будет обновляться. Если только мы не перезапустим P C! Тогда все снова работает нормально еще 8-24 часа! Проблема не связана с конкретным файлом, конкретным временем, конкретным пользователем или чем-либо еще. Поведение проблемы настолько изменчиво, что мы не можем четко определить причину проблемы, мы не можем найти какую-либо закономерность.
Наконец-то мы обнаружили одну вещь: не только сброс P C работает для решения проблемы, но и перезапуск процесса OfficeClickToRun.exe всегда помогает. Любопытно, я пытался отключить этот процесс навсегда, но затем Excel больше не запускается, поэтому я был вынужден включить его снова. Этот процесс необходим для работы Excel в Office 365.
Технология, которую мы используем для автоматического Excel refre sh: SQL планировщик заданий сервера 2014, выполнил сценарий PowerShell с COM-объектом Excel в нем (см. код ниже).
Также, когда процесс застревает, даже прямое выполнение скрипта Powershell больше не работает (до сброса). Powershell отказывается открывать Excel comobject после этого вообще. До ошибки Powershell прекрасно работает с тем же файлом Excel. Это может указывать на то, что проблема не связана с удаленным выполнением из SQL (запланированное задание), ни с олицетворением, ни с учетной записью пользователя и т. Д. c. Однако мы подозреваем, что эта автоматизация сама в какой-то момент вызывает проблему. Запуск приложения Excel каким-то образом блокируется, чтобы его можно было открыть с помощью comobject в Powershell. Как будто что-то внезапно потеряло привилегии для какого-либо объекта. Даже если процесс застрял (после появления первой ошибки), и прямой Powershell больше не работает, вы все равно можете открыть Excel вручную и обновить его sh без каких-либо проблем.
Я предполагаю, что проблема связана с этим процессом OfficeClickToRun. Я даже думал об автоматическом сбросе этого процесса после каждой итерации refre sh, чтобы сохранить его "fre sh". Однако для этой автоматизации у меня нет соответствующих привилегий для автоматического запуска Powershell от имени администратора. Или, может быть, есть способ?
Суммировать:
- Энергозависимый триггер миграции Office 365 SQL Поведение объекта Powershell Excel Com.
- Автоматизированный SQL> Powershell> Excel Процесс перестает работать с любым файлом Excel (не имеет значения) через 8-24 часа, иногда даже раньше.
- Процесс успешно запущен и работает после сброса P C или обработки OfficeClickToRun сброс.
- После зависания процесса даже прямое ручное выполнение кода Powershell не работает.
- Однако приложение Excel само по себе все еще работает правильно.
Заключительные замечания:
У нас есть все эти настройки объекта Excel App DCOM, Интерактивный пользователь, Remote Execution Et c. Et c. У нас также есть созданные папки Fakes "Desktop" и другие хитрости, которые нужно было сделать, чтобы этот автоматизированный процесс заработал. Мы также попытались удалить Office и установить экземпляр fre sh снова, это не помогло.
Вопросы: Есть ли у вас какие-либо предложения, которые могут вызвать эту проблему? Или как мы можем отследить эту проблему?
ОБНОВЛЕНИЕ: Может быть, мы должны что-то определить. Приложение DCOM excel установлено как Интерактивный пользователь (это необходимо для этого процесса и было раньше, в противном случае другие пользователи не смогли выполнить процесс вручную). Но кажется, что все автоматическое обновление завершается неудачно, когда все пользователи отключены (не вышли из системы) в течение некоторого времени. Как будто в процессе отсутствует активный пользователь для подключения на машине. Таким образом, проблема может возникнуть в одночасье, когда никто не работает на рабочем столе, или в течение дня, когда никто активно не подключен к компьютеру. Странно, что у нас не было такого поведения с предыдущей версией Excel.
Пример кода Powershell (только строки, связанные с Excel ниже):
function ReleaseRef ($ref)
{
if($ref -ne $Null)
{ ([System.Runtime.InteropServices.Marshal]::ReleaseComObject([System.__ComObject]$ref) -gt 0)
[System.GC]::Collect()
[System.GC]::WaitForPendingFinalizers()
}
}
#Start of the Procedure:
MakeReadWrite $TemplateFilePath
$excel = new-object -comobject excel.application
#$Excel.Visible = $false
$workbook = $excel.Workbooks.Open($TemplateFilePath)
$workBook.RefreshAll()
$workbook.Save()
$workbook.Close($False, $TemplateFilePath, $False)
$a = ReleaseRef($worksheet)
$a = ReleaseRef($workbook)
$excel.Quit()
$a = ReleaseRef($excel)