#vbscript #ssh #sas
#vbscript #ssh #sas
Вопрос:
Вот моя дилемма:
У меня есть некоторый код SAS, который в рамках своей [несколько] обширной обработки генерирует отчет о качестве данных в «Excel». Причина кавычек в том, что SAS действительно генерирует только XML-документ, который можно открыть в Excel.
Однако, как выясняется, большинство версий Excel будут жаловаться (через диалоговое окно) при открытии указанного XML-файла, а некоторые версии Excel даже не заходят так далеко.
Чтобы облегчить это, кто-то должен открыть этот файл «excel» вручную и сохранить его как настоящий файл Excel, прежде чем отправлять его другим [важным] людям.
Очевидно, что мы хотели бы автоматизировать это. И проблема даже не в этом. Я создал простую маленькую программу VBScript, которая открывает файл и сохраняет его как Excel. Бум. Проблема решена. Ну, не совсем.
Оказывается, что включение этого VBScript в обычную обработку данных — это PITA, поскольку все это происходит в Linux Box. Хорошо, пока, кажется, все не так плохо. Мы настраиваем виртуальный сервер терминалов Windows с идентификатором ограниченного использования, который может использовать ssh в поле и запускать определенную команду. Скрипт bash на Linux box теперь загружает XML-файл в виртуальную машину Windows, в папку вместе с VBScript и пытается удаленно выполнить VBScript, используя
cscript myscript.vbs myxlsfile.xls
Теоретически это должно сработать, но выдает ошибку с предупреждением:
Microsoft Excel не может получить доступ к файлу ‘myxlsfile.xls ‘. Существует несколько возможных причин: и т.д.
У кого-нибудь есть какие-либо идеи о том, что может пойти не так?
Вот VBScript:
Set oXL = CreateObject("Excel.Application")
Set FSO = CreateObject("Scripting.FileSystemObject")
oXL.DefaultFilePath = "C:Temp"
oXL.DisplayAlerts = False
oXL.Visible = False
If FSO.FolderExists(oXL.DefaultFilePath) Then
Set xmlFile = FSO.GetFile(oXL.DefaultFilePath amp; "" amp; TargetFileName)
oXL.Workbooks.Open(xmlFile.Name)
' -4143 is Excel 2003 format
oXL.ActiveWorkBook.SaveAs xmlFile.Name, -4143
oXL.ActiveWorkBook.Close SaveChanges = True
Set oFolder = Nothing
End If
oXL.DisplayAlerts = True
oXL.Quit
Set oXL = Nothing
Спасибо,
— A
Редактировать: Возможно, стоит повторить, что когда я запускаю это из командной строки на сервере Windows term, кажется, что все работает просто отлично. Я также попытался повторить все различные переменные path / filename, чтобы убедиться, что они вводятся правильно, и они (в обоих случаях)
Комментарии:
1. Вы когда-нибудь находили решение для этого? Кроме использования XP? Я сталкиваюсь с точно такой же ситуацией
2. Нет .. как я уже сказал в опубликованном мной ответе, мы создали виртуальную машину XP, и она работает с этим уже около 4 лет, и у нас не было никаких проблем, поэтому мы не собираемся ее трогать 🙂
3. Спасибо! Мы смогли разобраться с этим, изменив настройки dcom, с тех пор все работает нормально, хотя я бы все равно поделился этим.
Ответ №1:
Имеет ли пользователь, выполняющий скрипт, доступ к c:tempmyxlsfile.xls
?
Попробуйте запустить type c:tempmyxlsfile.xls
из сеанса ssh.
Комментарии:
1. Да, к сожалению, похоже, что это не проблема с разрешениями. Мы использовали тот же идентификатор, что и у SSHing, для прямого входа в TS и запуска VBScript и т.д.
2. Попробуйте это: В сеансе ssh
echo a > test.xls
, затем посмотрите, может ли скрипт VB открыться test.xls3. Я использую командную строку SSH, поэтому я использовал следующую команду: $SSHCommand -i <sshconnection_details> «cd c:UsersmyUsersmyDir amp;amp; echo a > test.xls amp;amp; cscript myscript.vbs test.xls «Я вижу, что файл xls создан, но при попытке открыть его в vbscript возникает та же ошибка
4. Просто чтобы все проверить, попробуйте проверить
FSO.FileExists(oXL.DefaultFilePath amp; "" amp; TargetFileName)
5. Как я и подозревал, FileExists вернул -1 .. Понятия не имею, почему.. Ах, Windows!
Ответ №2:
Есть ли у вас какой-либо сценарий входа в систему, который выполняется при интерактивном входе в систему, но не выполняется SSH-клиентом? Если файл существует по сетевому пути (я знаю, что в вашем примере вы показываете c:temp … но на всякий случай) и эти сетевые подключения не создаются, тогда это может вызвать у вас эту проблему. Это справедливо, даже если вы используете UNC-пути…
Комментарии:
1. Это хороший момент и одна из первых вещей, которые мы исключили, сделав именно это (используйте c:Users в качестве базовой папки). Также обратите внимание, что фактический vbscript находится в той же папке, что и файл xls, поэтому мы стараемся изо всех сил упростить для него работу 🙂
Ответ №3:
Если вы еще не решили эту проблему, я немного не понимаю, что вы делаете. Вы запускаете SAS в Linux и записываете XML-файл в Windows? Затем Excel считывает этот XLM-файл.
Прямо сейчас это не принесет вам никакой пользы, но если вы получите интерфейс SAS / Access для форматов файлов ПК (я предполагаю, что он доступен для Linux), вы сможете назначить libref с помощью движка Excel в Linux и указать его на каталог в окне Windows, чтобы затем вы могли записывать непосредственно из SAS на сервере в книгу Excel. Это то, что мы делаем в нашей среде AIX-Windows. Это не очень быстро, потому что он использует ODBC, но это надежно. Конечно, это требует дополнительного лицензирования и платы за программное обеспечение SAS.
Удачи.
Ответ №4:
Я решил эту проблему, используя виртуальную машину XP, на которой запускался код VBS. Он использует Office 2003. Мы не полностью исключили все переменные, из-за которых это не работало на виртуальной машине Windows 7 с Office 2007, но на данный момент это работает для нас, поэтому мы решили больше не тратить на это время. Единственным недостатком является то, что преобразованный файл при открытии в последней версии Office открывается в защищенном режиме. Для нас это не является большой проблемой, поскольку эта электронная таблица предназначена для людей, которые в любом случае используют Office 2003.
Спасибо всем за помощь, ребята. Ценю это.
— A