none
Ошибка ADO 3709 при открытии XLS-файла при запуске VBS в планировщике. RRS feed

  • Вопрос

  • Добрый день!

    Происходит непонятная вещь. Скрипт архивации данных подключается к XLS-файлу и считывает оттуда перечень каталогов, соответствующих тем или иным архивным заданиям. ОС — Windows Server 2008 Enterprise SP2 x64. При запуске скрипта напрямую из-под сеанса пользователя отрабатывается без проблем. При запуске планировщиком заданий от имени той же самой учётки (или другой, не играет роли) создание ADO-подключения к файлу срывается, при этом регистрируется Err.Number 3709 и Err.Description "Невозможно использование подключения для выполнения операции. Оно закрыто или не допускается  в данном контексте."

    Ниже привожу код функции создания подключения. В качестве аргумента ей подаётся строка "SELECT ArcName FROM [Лист1$]", лист с названием Лист1 в экселевском файле, разумеется, присутствует.

     

    Function ADO_DBConnection(sSQL)
    	'Подключение к файлу конфигурации, указанному в блоке конфигурации.
    	Dim objConnection, objRecordSet, sConnectionString
    	'Константы ADO (Active-X Data Object). Нужны для работы с файлом конфигурации.
    	Const adOpenStatic = 3
    	Const adLockOptimistic = 3
    	Const adCmdText = &H0001
    	Set objConnection = CreateObject("ADODB.Connection")
    	Set objRecordSet = CreateObject("ADODB.Recordset")
    	sConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Chr(34) & sFile & Chr(34) & ";Extended Properties=""Excel 8.0;HDR=Yes;"";"
    	On Error Resume Next 'Выключаем обработчик ошибок, чтобы иметь возможность записать ошибку обращения к файлу концигурации в текстовый лог.
    	objConnection.Open sConnectionString
    	objRecordSet.Open sSQL, objConnection, adOpenStatic, adLockOptimistic, adCmdText
    	If Err.Number <> vbEmpty Then 'В случае ошибок при открытии файла конфигурации записываем ошибку в текстовый лог и завершаем работу скрипта.
    		strItem = Now() & ": " & ErrorHandler("Ошибка открытия файла конфигурации " & Chr(34) & sFile & Chr(34) & " при помощи строки " & Chr(34) & sSQL & Chr(34))
    		Call WriteTextFile(LOGFILE, ForWriting, strItem)
    		eSubject = eSubject & " ошибка открытия файла конфигурации!"
    		Call SendEMail (eRcpt, eSubject, "Скрипт архивации общих папок на сервере " & sComputerName & " не смог открыть файл конфигурации, отчёт содержится во вложении." & eFooter, LOGFILE)
    		Wscript.Quit
    	Else
    		Set ADO_DBConnection = objRecordSet
    	End If
    	On Error Goto 0 'Включаем обработчик ошибок обратно.
    End Function
    

     

    17 января 2011 г. 7:13

Ответы

  • Может быть стоит попробовать жестко прописать ODBC-источник в панели управления, и затем обращаться к нему по имени, а не определять параметры при помощи ConnectionString?
    my blog: http://shserg.ru/
    • Помечено в качестве ответа me4huk 18 января 2011 г. 12:20
    18 января 2011 г. 10:38
  • Ага... вероятно, проблема в том, что для Jet 4.0 не существует 64-битного драйвера? Могу предположить, что, когда я запускаю скрипт напрямую, WSH почему-то знает, что надо использовать 32-битный драйвер. А когда скрипт запускается планировщиком, соответственно, WSH пытается искать 64-битный?

    Если это так, что надо указать в параметрах драйвера, чтобы исключить подобную ситуацию на 64x-системах?

    EDIT: Да, дело именно в том, как я запускал скрипт напрямую. Я запускал его из-под Total Commander, а он, разумеется, 32-битный. Соответственно, WSH искал правильный драйвер. При запуске из проводника я получаю точно такую же картину, как и при запуске планировщиком...

    • Помечено в качестве ответа me4huk 18 января 2011 г. 12:20
    18 января 2011 г. 10:35
  • Большое спасибо за помощь. Прописывание соединения в качестве источника ODBC помогло. Конечно, перед этим мне пришлось установить на 2008-сервер Microsoft Access Database Engine 2010 Redistributable (взял здесь), поскольку в x64-версии оснастки odbcad32 список доступных драйверов ограничивался только двумя SQL-соединениями. После установки MADE я попробовал изменить драйвер в строке соединения скрипта на Microsoft.ACE.OLEDB.14.0, однако это не помогло — скрипт просто завис при попытке установки соединения. А вот после прописывания ODBC-источника в системе и соответствующей правки скрипта всё заработало, как дОлжно.

    • Помечено в качестве ответа me4huk 18 января 2011 г. 12:20
    18 января 2011 г. 12:19

Все ответы

  • файл Excel, к которому происходит обращение через ODBC, лежит на компьютере, на котором запланировано задание?


    my blog: http://shserg.ru/
    17 января 2011 г. 15:21
  • Виноват, из приведённого куска неясно, откуда берётся файл. Да, конфигурационный файл лежит на локальном компьютере. Вот вырезка из кода:

    Const CONFIG = "BackupConfig.xls" 'Файл конфигурации, перечень архивируемых ресурсов.
    Dim CONFDIR
    CONFDIR = "\Scripts\" 'Каталог установки архиватора. Это НЕ КОНСТАНТА! Далее по коду он модифицируется с учётом пути к ProgramFiles, поэтому нужны открывающий и закрывающий бэкслеш.
    CONFDIR = WshShell.ExpandEnvironmentStrings("%ProgramFiles(x86)%") & CONFDIR 'Если запускаемся на 64-х разрядной системе.
    sFile = CONFDIR & CONFIG 'Собираем полное имя файла конфигурации.
    

    18 января 2011 г. 5:46
  • >On Error Resume Next 'Выключаем обработчик ошибок, чтобы иметь возможность записать ошибку обращения к файлу концигурации в текстовый лог. objConnection.Open sConnectionString

    Попробуйте закомментировать On Error Resume Next. Если верить сообщению об ошибке, которое у вас возникает, то соединение не открыто, а это значит, что, должна происходить ошибка на следующей строке objConnection.Open sConnectionString. Интерсно было бы узнать, так ли это на самом деле? И, если так, то какая возникает ошибка?


    my blog: http://shserg.ru/

    18 января 2011 г. 6:26
  • Да, ошибка возникает на строке objConnection.Open sConnectionString, рапортует о ней Windows Script Host. Данные ошибки следующие:

    Источник: ADODB.Connection

    Код: 800A0E7A

    Ошибка: Не удается найти указанного поставщика. Вероятно, он установлен неправильно.

    18 января 2011 г. 10:29
  • Ага... вероятно, проблема в том, что для Jet 4.0 не существует 64-битного драйвера? Могу предположить, что, когда я запускаю скрипт напрямую, WSH почему-то знает, что надо использовать 32-битный драйвер. А когда скрипт запускается планировщиком, соответственно, WSH пытается искать 64-битный?

    Если это так, что надо указать в параметрах драйвера, чтобы исключить подобную ситуацию на 64x-системах?

    EDIT: Да, дело именно в том, как я запускал скрипт напрямую. Я запускал его из-под Total Commander, а он, разумеется, 32-битный. Соответственно, WSH искал правильный драйвер. При запуске из проводника я получаю точно такую же картину, как и при запуске планировщиком...

    • Помечено в качестве ответа me4huk 18 января 2011 г. 12:20
    18 января 2011 г. 10:35
  • Может быть стоит попробовать жестко прописать ODBC-источник в панели управления, и затем обращаться к нему по имени, а не определять параметры при помощи ConnectionString?
    my blog: http://shserg.ru/
    • Помечено в качестве ответа me4huk 18 января 2011 г. 12:20
    18 января 2011 г. 10:38
  • Да, я попробую этот вариант, спасибо. О результатах отпишусь.
    18 января 2011 г. 10:58
  • Большое спасибо за помощь. Прописывание соединения в качестве источника ODBC помогло. Конечно, перед этим мне пришлось установить на 2008-сервер Microsoft Access Database Engine 2010 Redistributable (взял здесь), поскольку в x64-версии оснастки odbcad32 список доступных драйверов ограничивался только двумя SQL-соединениями. После установки MADE я попробовал изменить драйвер в строке соединения скрипта на Microsoft.ACE.OLEDB.14.0, однако это не помогло — скрипт просто завис при попытке установки соединения. А вот после прописывания ODBC-источника в системе и соответствующей правки скрипта всё заработало, как дОлжно.

    • Помечено в качестве ответа me4huk 18 января 2011 г. 12:20
    18 января 2011 г. 12:19