getting error while opening excel workbook in scheduled agent - lotus-domino

I got a problem in scheduled agent in lotus script while opening csv workbook.It simply opens workbook from Excel and reads the data.
It works perfectly fine when I run manually. It throws when schedule at workbooks.open line.
Agents Settings : Allow resticted operations with full admin rights.
Code :
Set xlApp = CreateObject("Excel.Application")
xlApp.Visible = False
xlApp.DisplayAlerts = False
Print "New filepath=" & filepath
xlApp.Workbooks.Open filepath ' Open the CSV file
Set xlWorkbook = xlApp.ActiveWorkbook
Set xlSheet = xlWorkbook.ActiveSheet
filepath=C:\Temp\transit_15102008.csv
Error thrown at log.nsf
printing: ERROR : Transfer Files agent- Microsoft Office Excel: Microsoft Office Excel cannot access the file 'C:\Temp\transit_15102008.csv'. There are several possible reasons:
• The file name or path does not exist.
• The file is being used by another program.
• The workbook you are trying to save has the same name as a currently open workbook. at line-55
There is only one worksheet in the Excel.
I am not able to figure out the issue. Please somebody help me to resolve. Thanks in advance.

When you run your agent manually, it runs in your workstation context where (I assume) there is MS Office installed.
But when your agent runs as scheduled, it runs in the server context, and if you don't have MS Office installed on the server, or there's no file on the path: C:\Temp\transit_15102008.csv on the server, then your agent fails.
Solution:
Make sure you have MS Office properly installed on the server where your scheduled agent runs.
Make sure that there is file present on the path C:\Temp\transit_15102008.csv on your server where your scheduled agent runs.

Related

Running an excel macro from task scheduler

I am trying to run a macro using task scheduler and it looks like it executes the VBScript file but it doesn't actually execute any of the code in the macro.
The pathway for the workbook is
C:\Users\cdurrell\Desktop\Test Auto 1.xlsm
The macro is called TestAuto
And the Script file has the pathway
C:\Users\cdurrell\Desktop\TestAutoScript.txt
I originally was using the following script file
'Write Excel.xls Sheet's full path here
strPath = "C:\Users\cdurrell\Desktop\Test Auto 1.xlsm"
'Write the macro name - could try including module name
strMacro = "Update" ' "Sheet1.TestAuto"
'Create an Excel instance and set visibility of the instance
Set objApp = CreateObject("Excel.Application")
objApp.Visible = True ' or False
'Open workbook; Run Macro; Save Workbook with changes; Close; Quit Excel
Set wbToRun = objApp.Workbooks.Open(strPath)
objApp.Run strMacro ' wbToRun.Name & "!" & strMacro
wbToRun.Save
wbToRun.Close
objApp.Quit
'Leaves an onscreen message!
MsgBox strPath & " " & strMacro & " macro and .vbs successfully completed!", vbInformation
'
and it would make the excel workbook read only and not execute the code in the macro.
Then I took out the line
wbToRun.Save
and now it doesn't make the excel workbook read only but it still doesn't execute the code.
Any pointers or corrections are welcome! Thanks!
I'm not sure if you are still facing this issue, but I found my own solution since I was experiencing the same trouble. It is based on this old answer in Super User by squillman:
https://superuser.com/a/579901
Open Component Services (Start -> Run, type in dcomcnfg)
Drill down to Component Services -> Computers -> My Computer and click on DCOM
Config
Right-click on Microsoft Excel Application and choose Properties
In the Identity tab select This User and enter the ID and password of an interactive user account (domain or local) and click OK
Now, what else I needed to do?
Configure the scheduled task with the same account that I configured in step 4. I tried with the service account and failed.
Run whether user is logged or not.
After this, I was able to run it properly.
In my case it started working once I checked 'run with administrative privileges' in the task settings.

Project Server 2013 File Save Without Prompt

I’m trying to save a file that I previously opened on Project Server 2013. The only updates I’ve made to the files is to set the status date and move unfinished tasks. I’m running the file in excel VBA. I can share the complete set of code but I do not think it is necessary. If I run the macro without saving the files everything runs perfectly. All I need to do is get the files to save without prompting me and I’m done. All help is appreciated.
Dim appPJ As MSProject.application
Set appPJ = New MSProject.application
appPJ.FileOpenEx Name:="<>\" & strFileName, ReadOnly:=False, Noauto:=True, IgnoreReadOnlyRecommended:=True, DoNotLoadFromEnterprise:=False
'Update the status date and move unfinished tasks to the future
appPJ.ProjectSummaryInfo StatusDate:=dateStatusDate
appPJ.UpdateProject All:=True, UpdateDate:=dateStatusDate, Action:=2
'Call the various read data only report routines
appPJ.DisplayAlerts = False
appPJ.FileCloseEx pjSave, True, True
The line above will not save to server with a prompt.

Can't open xlsm file from SSIS package job

I have a number of SSIS jobs that open some Excel files and manipulate them. The task within the job that opens the Excel file is basically the same in each job, it just points to a different Excel file. Each of these jobs work fine except for one. But even this one works when ran manually from the package and not in the job.
The applicable code is:
Dim reportLocation As String
Dim oXL As Microsoft.Office.Interop.Excel.Application
Dim oWB As Microsoft.Office.Interop.Excel.Workbook
reportLocation = "\\testlocation\share\test.xlsm"
'Open Excel instance
oXL = New Microsoft.Office.Interop.Excel.Application
oXL.Visible = False
'Open the Excel file to edit
oWB = oXL.Workbooks.Open(reportLocation) 'Error here
The error received is as below:
Microsoft Excel cannot access the file '\\testlocation\share\test.xlsm'.
There are several possible
reasons:
• The file name or path does not exist. • The file is being used by
another program. • The workbook you are trying to save has the same
name as a currently open workbook. at
Microsoft.Office.Interop.Excel.Workbooks.Open(String Filename, Object
UpdateLinks, Object ReadOnly, Object Format, Object Password, Object
WriteResPassword, Object IgnoreReadOnlyRecommended, Object Origin,
Object Delimiter, Object Editable, Object Notify, Object Converter,
Object AddToMru, Object Local, Object CorruptLoad) at
ScriptTask_ffa2c543b1224c3987d5764694df1079.ScriptMain.Main()
This was the latest package to be created, and was a copy/paste job, just changing the locations it looks for the files. I have checked all permissions and there is no issue there. I've even given access to "Everyone" to see if that was an issue, but the same error occurred. The file definitely exists in the location and it is not open by anyone. What possible reason is there that this specific file can't be opened when run in a SQL job but can be opened when run manually in the package? I have also tried changing the job to run the package as a user with full admin access via a proxy. But still no joy.
This does not look like a valid path to me:
\\testlocation\test.xlsm
You at least need a share name after the host name:
\\testlocation\Share\test.xlsm
How do the paths look for your working files? I'm guessing they have a share.
Having revisited some answers on here for similar questions I was able to find the solution. This can be seen at Microsoft Office Excel cannot access the file 'c:\inetpub\wwwroot\Timesheet\App_Data\Template.xlsx'
I created the directory C:\Windows\SysWOW64\config\systemprofile\Desktop on the server and it miraculously now works. I had looked at this yesterday and thought the directory already existed so didn't implement this solution. But having a second look at it today shows the directory didn't exist and creating it fixed it.
Now the question is, why does this work?! But that is possibly another question.

How to open specific version of Word 2007/2010 in Excel

I have both Word 2007 and 2010 installed. I need to open Word from within Excel but I need to specify which version I need to open within VBA.
I've tried late binding
Dim wordApp2007 As Object
Dim wordApp2010 As Object
Set wordApp2007 = CreateObject("Word.Application.12")
wordApp2007.Visible = True
Set wordApp2010 = CreateObject("Word.Application.14")
wordApp2010.Visible = True
but both open Word 2010
I've also tried early binding by using
Dim wordApp As Word.Application
Set wordApp2007 = New Word.Application
wordApp2007.Visible = True
and setting references to the Word 12.0 object model but this still opens Word 2010
If I register each version of Word using
"C:\Program Files\Microsoft Office\Office12\WINWORD.EXE" /regserver
"C:\Program Files\Microsoft Office\Office14\WINWORD.EXE" /regserver
then the version registered opens but then I can't open open the non-registered.
Can anyone help and show me how to open a specific version of Word within Excel using VBA?
Thank you
Edit: Example code....
Option Explicit
Dim wordApp2007 As Word.Application
Sub Word_InfoEarly()
'early binding
Set wordApp2007 = New Word.Application
wordApp2007.Visible = True
'other Stuff
Stop
wordApp2007.Quit
Set wordApp2007 = Nothing
End Sub
Sub Word_InfoLate()
Dim wordApp2007 As Object
Dim wordApp2010 As Object
Set wordApp2007 = CreateObject("Word.Application.12")
wordApp2007.Visible = True
Set wordApp2010 = CreateObject("Word.Application.14")
wordApp2010.Visible = True
'other Stuff
Stop
wordApp2007.Quit
Set wordApp2007 = Nothing
wordApp2010.Quit
Set wordApp2010 = Nothing
End Sub
This is a work around:
TaskID = Shell("C:\Program Files\Microsoft Office\Office12\WINWORD.EXE",vbHide) '2007
'TaskID = Shell("C:\Program Files\Microsoft Office\Office14\WINWORD.EXE",vbHide) '2010
GetObject(,"Word.Application")
You would also need to test if a previous version of word is open, or use something other than a basic GetObject to activate the window, else there's no guarantees that it will get the right version.
The other way would be to pass the document name in the Shell command, and then GetObject could be called with the document name
This may further explain why the code works some times and not others.
My observation on the situation of the command
'Set wordAppxxxx = CreateObject("Word.Application.xx")'
working or not on your computer is that it is a function of the latest update you get from Microsoft.
Why I believe this:
I have an application that converts a text file to a Word document for backwards compatibility with some legacy apps. The best plan includes using a version of Word similar to the version the legacy apps were designed with/to. As a result, I searched on how to invoke a legacy version of Word as opposed to the default offering on my computer which is Word 2010.
The solution noted in this discussion chain provided the answer to my question. (Thank you Stack Overflow contributors!) I wanted to use Word XP, so I looked at my directories and observed that Word XP (aka Word 2002) is a member of Office 10, so I created the command
'Set wordApp2002 = CreateObject("Word.Application.10")'
and my program launched Word 2002 and the world was a happy place.
Over the weekened, I had an update to my computer. I control the updates via an app which gives me control over when updates occur such that I can observe changes to my configuration. This morning (9/30/13) I turned on a computer that had a Word update. I did not know this until after I had made one run of my app from last week. The app ran fine and invoked Word 2002 as expected.
But then I got the banner page informing me of a Word 2010 update that was installing itself.
Afterwards, I ran the app that worked so well for me last week and once today. Now, after the Word update (immediately after!), the same code now launches Word 2010 despite the fact that the command line invoking Word 2002 has not changed.
This appears strong evidence that a Microsoft update tweaked the settings that previously allowed the VB code to work as expected. This might be a good item to bring to Microsoft's attention so see if we can get this item stabilized in subsequent update packages to allow consistent behavior in future releases.
I hope this is helpful,
JeffK
I wasted half a day on this, and want to help prevent others doing the same! I'm running Windows 7 and Office 2013 and 2010 on the same laptop. I wanted to get Access VBA to open up an old version of Word, as Word 2013 call-outs are printing with thick black borders.
Having tried lots of variations, here's my code which worked:
Sub GetWordReference()
'finally got Access to open old version of Word
'open Word 2010
Shell "C:\Program Files (x86)\Office 2010\Office14\winword.exe"
'open Word 2013
'Shell "C:\Program Files\Microsoft Office 15\root\office15\winword.exe"
TryAgain:
On Error GoTo NoWord
Set word2010 = GetObject(, "Word.Application")
On Error GoTo 0
word2010.Visible = True
'word2010.Documents.Add
'word2010.Selection.TypeText "This is Word " & word2010.Version
Exit Sub
NoWord:
Resume TryAgain
End Sub
I can't get the SO code editor to show this correctly, but copying and pasting should work.
I had a similar issue, and thought I would detail my experience for those that stumble across this in the future.
In my situation, I had a Powerpoint macro that was supposed to open a file dialog for the user to select some Excel files and then create tables from the data; I had no problem with it until I recently installed Excel 2003. Now Powerpoint was opening up an Excel 2003 file dialog, which would raise errors when trying to select a *.xlsx file. It didn't matter if I used Excel.Application.10 or Excel.Application.14 in my code to create the Excel object, it was always an Excel 2003 file dialog.
I noticed in Explorer that *.xlsx files were set to be opened in Excel 2010 and *.xls files were set to be opened in Excel 2003. I tried to usual way to reset *.xls files to be opened in 2010 to no avail. I ended up having to delete the registry key and repair Office 2010. Now that all Excel files open in 2010, my problem has been fixed.
I know my problem was a bit different than yours, but I think my experience could help lead to a solution. I think any solution will end up relying on some registry editing.
This is a VB.NET solution:
Sub Word_InfoLate()
Dim wordApp2007 As Object
Dim wordApp2010 As Object
This is a bit intimidating to some, but there may be a registry edit that can solve this.
I am unable to test as I only have one version of MS Office available to me, however, previous versions still have registry keys left over.
I found the 2007 version of Word in the registry, and it's default location is C:\program Files\Microsoft Office\Office14\WINWORD.EXE" indicating that older versions of Word are registered to the newest version install location as it's new default.
What you might be able to do is navigate to the registry location
HKEY_CLASSES_ROOT\Word.Documet.12\shell\Open\Command
Change the (Default) key to read "C:\program Files\Microsoft Office\Office12\WINWORD.EXE" /n "%1"
In theory whenever
Set wordApp2007 = CreateObject("Word.Application.12")
is invoked it may probe the registry for the location of the executable, and find the correct path.

SSIS Excel RefreshAll() task SQL job fails when no one logged in

A few months ago, I made a SSIS package that is used to refresh a couple excel worksheets (+few other things)
Now, my college that is still on the project reports this weird behavior.
The SSIS package is scheduled as SQL Agent Job.
It runs hourly from 8am00. At 8am it always fails, his conclusion: at 8am is no one logged on the server.
The second time, at 9am, the job runs OK. (RefreshAll worked) His conclusion: there is always someone logged on the the server via RDP at that moment.
(In fact I don't know about the other runs later on the day)
The task is a VB Script task that calls the Excel Interop dlls. I remember having difficulties to get it working until I installed Excel 2010 x86 on the server. -> Excel is fully and legitimately installed on the server.
My guess and determination at that moment was that it sometimes went wrong somewhere and Excel did not close properly. When I opened taskmgr I found +10 instances of Excel.exe running... This was during development.
My college did an interesting test: scheduled the job every minute and logged on and off a few times to the server. Every time no one was logged on to the server (RDP) the job failed. When logged on, the job ran OK !
Below the code that is used in the 'RefreshAll' script task.
I also used threading.sleep because otherwise I got timeout errors. Found no other way.
Thanks in advance!!
L
Public Sub Main()
Dts.TaskResult = ScriptResults.Success
Dim oApp As New Microsoft.Office.Interop.Excel.Application
oApp.Visible = False
'oApp.UserControl = True
Dim oldCI As System.Globalization.CultureInfo = _
System.Threading.Thread.CurrentThread.CurrentCulture
System.Threading.Thread.CurrentThread.CurrentCulture = _
New System.Globalization.CultureInfo("en-US")
Dim wb As Microsoft.Office.Interop.Excel.Workbook
wb = oApp.Workbooks.Open(Dts.Variables("User::FileNameHandleFull1").Value.ToString)
oApp.DisplayAlerts = False
wb.RefreshAll()
Threading.Thread.Sleep(10000)
wb.Save()
wb.Close()
oApp.DisplayAlerts = True
oApp.Quit()
Runtime.InteropServices.Marshal.ReleaseComObject(oApp)
End Sub
End Class
Excel is a client application and normally it does require to have active user session on a machine it runs on. For a job like this, I would consider other approaches not involving working with excel process, eiter:
store the result in a sql server table, then use linked table from excel sheet to pull the data.
use export as .csv (comma separated values)
use 3rd party controls that write Excel format
they may fix it in next version of Excel?