My vb application is used to generate the excel reports.During the last run it got failed in between but the excel process still running in the background on server.
The problem is there are some other applications that uses excel process to generate reports. I need to terminate the particular instance of excel which was still running at the background.
I don't know about the task manager but Sysinternals Process Explorer would give you that information. It lists all processes in a tree view displaying parent/child process hierarchies. http://technet.microsoft.com/en-gb/sysinternals/bb896653.aspx
I asked this question before and the bad news is, that there is no straightforward way to do that.
What can be done: When you start up excel in your application store the PID (if available, I am not sure) and / or the path of the created document. In case of an error, terminate the specific excel process by PID. Or if that is not possible: iterate over all open excel instances and find the one which has opened the path - than kill that instance. The latter approach is problematic in multi user environments, as Excel does not react well when used by multiple applications.
The best way would be to get rid of excel on the server altogether and move to an independent excel-writing library like EPPLUS or Aspose.Cells or other alternatives. But I do not know, if these libraries are still available for VB6. Please note, that Microsoft advises against using Office on a server
Related
If I wanted to check if an application is already open or not, how can we check that with process exists action in utility VBO in Blueprism? It is asking for process name when I go with process exists action as input. I have given a process name where we can see it in the task manager but it is not producing the desired results.
For an example, if I want to launch a Google page through BluePrism but it is already open, now I want to know whether this Google page is open or not. For this we can use Utility VBO but I am not getting it.
How to fix this problem?
"Process exist" action allows you to check if the process with this name is running right now in windows. To use that, you need to have a proper, process name. For example for internet explorer it's "iexplore", and for MS Excel it's just "excel".
Using this action you can get only understanding if the process exists or not, and nothing more.
If you'd like to know if the webpage google.pl had opened, then you'll need to use other techniques - namely using application modeler, spying windows and using a variety of blueprism actions.
While launching any web application, BOT should attach the process to window/application, if attach action returns false then only BOT need to launch the site in IE. For Attach action there will be different inputs are available some of them are listed below:
ProcessName
WindowText
I want to know whether my add-in is running in Word, Excel or Powerpoint. I need a solution that works in the desktop version of the applications (but preferably for the online version as well).
Is this somehow possible?
The reason I'm asking is twofold:
I want to style the add-in app in the colors of the host application.
I submit the document to a webservice. I want to provide a filename as well and need to know if I should postfix with .docx, .xlsx or .pptx.
There isn't a straightforward way to determine the current host. I would also discourage going down the "single manifest, multiple hosts" path in the first place. As the APIs have matured, more and more functionality has become host specific. The most obvious examples being ExcelAPI and WordAPI.
This isn't to say you should build multiple web apps, just that you should maintain multiple manifests. Each manifest can specify a distinct "landing page" where you can make some session level settings that tell the rest of the App which host it's talking too.
The other benefit of this approach is you can be more selective about which Add-in Commands you declare and where in the ribbon they show up. In some cases you might have functions available in Excel that don't show up at all in Word or PowerPoint.
I am running an automated Data job on a windows server that outputs a SAS dataset everyday. On top of this, I have an Excel Report connected via Excel's Local Data Provider.
My problem is, that the Data Connection needs to be manually refreshed by a person with SAS installed on their PC. I have tried writing a piece of SAS code that opens the Excel file on the server and then triggers a piece of VBA that did the refreshing, before closing and saving. This works perfectly if I'm logged into the server. But it doesn't seem to work if nobody's signed in. I believe this has something to do with having an active user session.
UPDATE
The process that I use to connect to a local data source from Excel, looks like this:
Data Connection Wizard
Select SAS Local Data Provider from OLE DB Providers
Add the Route to my SAS Dataset as data source
Select My source table and create a Pivot Report
Is there any way to do something like this?
When you want to run Excel unattended, thus no interactive user is logged on, you can do this with a Windows service. You have to ensure some settings for Excel, as well as it is important how you start excel.
Be aware of Microsoft does not support, or even suggest you to do something like this. Excel is a client software, it is exactly the opposite of a piece of software that is easy to maintain running as as service. Read this excellent article Considerations for server-side Automation of Office about the topic. Even when a little old (talking about Office 2003) it is still state of the art.
Please consider these conditions:
You cannot use the System or Network account, you have to let the windows service running under an account that at least have excel started once. This cannot be done with the named ones (as they cannot be used as interactive users)
Excel has to be opened at least once with the user under with the windows service account will run. You'll have to configure dcom settings, open vba once to initialize it, and most probably set some settings like "trust vba model" to be able to programmatically access Excel
last but not least when starting Excel you have to start it with loading the user profile. The Process.Start method in c# allows exactly that by just setting a boolean value to true.
Doing it like this, Excel should just start fine and update data connection with the VBA.
You may want to implement that windows service in c#, as it is really easy, have a look: Creating a Basic Windows Service in C#.
When using c#, be aware of you have to correctly dispose interop objects, pretty good described in How to properly clean up Excel interop objects
I have an application (web) which suppose to open separate excel process for each session. When i try this, server opened only 20 process, is it a restriction or is their a way to open more than 20 Excel.exe process.
Thanks
I think this depends on your system resources.
However I can tell you from personal experience that Excel Interop is not a recommended solution to web applications e.g. C# ASP.NET. See here even: https://support.microsoft.com/kb/257757?wa=wsignin1.0
Why else?:
Excel Interop uses a lot of system resources and your web application will soon run into many performance issues.
Excel Interop has to be installed on the server and there are also issues with the process identity. Installation and configuration is sometimes hard and differes for 32 bit and 64 bit systems.
Sometimes for, God knows what, reasons Excel Interop processes will not close immediately (not only if some Interop resources are unreleased). Then you will have to close these processes yourself which is a real pain.
Why not use OpenXML or even better ClosedXML? You will see your code running even 100x faster with Excel files as OpenXML/ClosedXML treats Excel files as XML files and does not create additional processes for intermediary operations.
CloseXML link: https://closedxml.codeplex.com/
Wanted some opinions on which method is a better practice. We have a sales report that MUST be generated in a very specific format (down to the row colors and fonts).
I already have written a macro which pulls from our database and populates the entire workbook in about 15 seconds. The question is how should it be populated?
1) Process server-side: Users initiate the request on the intranet page. ASP.NET opens the workbook template, executes the macro and serves back the final sheet.
2) Process locally: Users download the blank template, run from their desktops which automatically connect to the database.
I like the first one because I can enforce the template, timing, users, and security of the data. But is running Excel automation on an internet web server recommended? I like the second option, but I'm afraid of losing standardization as template sheets begin floating around the company.
As for server side:
I highly.. HIGHLY.. recommend checking out the OpenOffice/LibreOffice XML format for spread sheets.
You can use the localc binary in headless mode to convert the XML file to XLSX or what have you. I use it to create PDF files instead of using ReportLab.
Alternatively here are some other projects that attempt to write to Microsoft formats directly:
http://pypi.python.org/pypi/xlrd
http://pypi.python.org/pypi/xlwt
As for client side:
If you expect the user to be only using Excel and not any other spreadsheet software then go ahead and use an ODBC data source. ODBC will have to be configured per user unless you use some fun VBScript to pull the data from an HTTP server every time it is loaded. There is also the option of making an XLS spreadsheet that simply holds the data and including it into an XLS document as well which would be both a server and client XLS requirement.
Go for server side. Makes information simple to archive and share and will most likely be multi-platform as well.
If you like to use your first option, then you want to avoid using VBA on an installed instance of Excel on the server. This is extremely resource intensive and does not scale well. Instead, if you are writing ASP.NET code, then you should try using the Microsoft Office Interop functionality that is built into the .NET framework. It should possible to adapt your existing VBA code to run under ASP.NET with some changes, but you will have a much more reliable product in the end.
Example Code
However, as #whardier points out in his response, if this were for a large scale or public site, the suggestions he makes would be much more suitable and would scale much further.