NOTE: This page has been translated automatically from Russian to English. Original page.



Working with Excel in the background job

There was a problem. By e-mail messages with attachments come Excel spreadsheets. Receiving mail is produced integrated customer 1C background job. It was necessary to schedule several times a day to retrieve new messages from the attachment and load data from them. Then I ran into a problem - work with Excel in the background job either through COM, or through ADO failed. It throws out the error. Nowhere in the network a clear solution to the problem I found. As a result, collecting the crumbs of information from different sources (and sometimes not at all related to 1c) and a few days of torment nevertheless I decided this issue. Below I will describe his decision to help the same as I)

I will begin my story.

Attempting to connect to Excel through the COM object

 ExcelApp = New COMObekt ( "Excel.Application"); 

resulted in an error "The interface is not supported."

Using ADO

 CtrokaSoedineniya = "Provider = Microsoft.ACE.OLEDB.12.0; Data Source =" +
    FileName + "; Extended Properties =" "Excel 8.0; HDR = NO; IMEX = 1" "";

SoedinenieADO = New COMObekt ( "ADODB.Connection");
SoedinenieADO.ConnectionString = StrokaSoedineniya;
SoedinenieADO.Open ();

there is a "specified provider is not found" error.

Just specify that Microsoft Office has been installed on the server and in the normal processing starts (not in the background job) everything went bang.

Since the background tasks are performed on behalf of the user, under which the 1C: Enterprise server (usually USR1CV82), then there was a logical assumption, then this user does not have sufficient rights. For the experiment, this user had administrator rights, and issued a background job completed successfully. However, this was not an option. Required minimum possible rights and I plunged into the world of information search on the Internet.

So. The first thing we found out is that the user USR1CV82 should be given permission to run DCOM Microsoft Excel Application (ask a petition, can be confused in terms, but the meaning is, what to do, I think, will understand).

To do this:

1. Click the Start button and select Control Panel.

2. Double-click Administrative Tools icon and select Component Services.

3. In the left pane of the window "Component Services" by double-clicking the item Component Services, double-click Computer, and select My Computer.

4. Select the folder Configuring DCOM.

5. In the details pane, find the Microsoft Excel Application object, right-click it and select Properties (there is a caveat, which I'm pretty long promuchalas - if the server is 64-bit, and the edition of Office also needs to be x64, or Microsoft Excel Application object is not in the list, and right for him, I have not managed to set up is not reinstalled Office).

6. Open the Security tab.

7. In the Launch Permissions select Customize, and then click Edit.

8. Add user USR1CV82.

Source: http://technet.microsoft.com/ru-ru/library/cc778126(WS.10).aspx

The following explanatory screenshots.

However, after making a background job settings described above have not worked.

When working with COM object an instance of Excel is successfully created, but it was impossible to open the file

 ExcelApp = New COMObekt ( "Excel.Application");
FaylExcel = ExcelApp.Workbooks.Open (filename); // ERROR! 

an error message

An exception (Microsoft Excel): Microsoft Excel application can not access the file "C: \ xls_test \ test.xls". This may be caused by one of the following reasons.

• A nonexistent file or path.
• The file is used by another program.
• The name of the book you are trying to save is the same as the name of another book, open at the moment.

Attempts to connect via ADO betrayed all the same message about the absence of the supplier.

The search for open spaces in the network were continued and a solution has been found yet:

You must create a folder

  • for Windows Server x64

    C: \ Windows \ SysWOW64 \ config \ systemprofile \ Desktop
  • for Windows Server x86

    C: \ Windows \ System32 \ config \ systemprofile \ Desktop

This location of the folder specified for Office 2007. For Office 2010, regardless of the platform on the need to create the folder C: \ Windows \ System32 \ config \ systemprofile \ Desktop ( this fact also spent quite a few of my time). In general, if you create a folder, and the error does not disappear, create the second. It is also necessary to give the right to the user folder you created USR1CV82. Practice has shown that sufficient permissions issued by the system.

Source: http://social.msdn.microsoft.com/Forums/en-US/b81a3c4e-62db-488b-af06-44421818ef91/excel-2007-automation-on-top-of-a-windows-server-2008- x64

After the performed all the settings on the test server background job finally was successful.

However, on the production server while connecting to Excel via COM I was waiting for the debacle - the job just hangs and complete it could only restart the 1C: Enterprise server. It freezes when opening a file (FaylExcel = ExcelApp.Workbooks.Open (filename)). I guess that when you open an Excel opens some window and waits for user response. But could not be verified as to access to the server I did not have all the settings on my request, it produced an admin.

As a result, all vzeletelo using ADO and successfully works.

I hope this article will help anyone really save time in the implementation of these tasks.

ps Oh and forgot to mention that the user USR1CV82, of course, must be the right to be treated Excel files.

1C:Enterprise Developer's Community