Context:
VBA macro embedded in an MS-Word document.
Old code running for 15+ years under Word 2003 without issue.
Upgraded to Word 2019
Existing/Previous RTFs open without issue
Upgraded server from "Windows Server 2008 R2 Standard" to "Windows Server 2016 Datacenter"
The troublesome RTF is a copy of another RTF that works without issue. No edits were made.
I make the call
On Error GoTo docerr
Set gobjDoc = Documents.Open(gstrTEMPLATE_PATH + gstrTEMPLATE_NAME)
docerr:
WriteLog ("ERROR Documents.Open: " & Str(err.Number) & "-" & err.Description)
where gstrTEMPLATE_PATH + gstrTEMPLATE_NAME provides a fully qualified path. I've logged this value it continues to be accurate.
For the new/copied RTF, the interpreter gets to the Documents.Open statement and never returns. No error is thrown.
Does anyone know why is doesn't return? Is there a way to force a return?
I added the parameter OpenAndRepair:=True with no effect.
FYI: This is my first question on this forum.
The Considerations for server-side Automation of Office article states the following:
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
Microsoft strongly recommends that developers find alternatives to Automation of Office if they need to develop server-side solutions. Because of the limitations to Office's design, changes to Office configuration are not enough to resolve all issues. Microsoft strongly recommends a number of alternatives that do not require Office to be installed server-side, and that can perform most common tasks more efficiently and more quickly than Automation. Before you involve Office as a server-side component in your project, consider alternatives.
For example, the Open XML file formats are a public standard. See Welcome to the Open XML SDK 2.5 for Office for more information.
Also you may conside using any third-party components designed for the server-side execution, especially, for RTF files.
Related
Am using MS Access 2016 to develop an application managing images. But some of my users are still using MS Access 2007 on their computers. And the receive the error "unrecognized database format".
So I would like to know if there is any solution for this. Like making my application compatible for previous versions.
I did some researches for days but not satisfied yet.
Need any help, solution or advice please. Thanks
Develop using the lowest version that your application will address, here 2007.
A newer version - 2010 and onwards - will run an older with no problems. However, 2007 is 32-bit only, thus - if you use API calls and some users run Access 64-bit - you must take care of that.
I am writing a VBA script to import data from an Access database to a remote database server. (It happens to be PostgreSQL, but I don't think that's very relevant.) At the moment, my scripts are embedded inside an Access database. However, I would like to version my scripts like I do my other source code: as plain text so SVN can give me good change tracking.
I would also prefer not to have to deliver the source files to the client for them to use the script. In other words, I would like to deliver the import tool already compiled into the Access database. Is it possible to do so?
Or am I chasing the wrong rabbit? Is there a way I can use the Access libraries without embedding any code into the Access database? My searching suggests not, but I'm open to the possibility. This is the first thing I've ever done with VBA, so there's a ton I don't know, I'm sure.
I think I was going down the wrong rabbit hole (and I think I was using a non-existent idiom). Turns out that there are some .NET interop DLLs for Office. My machine seems to have the .NET interop DLLs already installed with Office, so all I had to do was add a reference to the Microsoft.Office.Interop.Access DLL and create an application object:
var app = new Microsoft.Office.Interop.Access.Application();
I think a .NET app is going to be more suited to my needs. I'm not going to be doing a lot of Access specific things. This will allow me to have my source under version control as usual. The only downside is that any development machine (and build server, if I automate the build) will need Access installed, but that was going to happen with a VBA script, anyway.
If you don't want to do it within Access, you may want to tag this differently.
You can deliver your database to the client as an MDE file, which is a compiled and stand-alone Access database. The client will not be able to see the modules or other VBA code in this format, if that is your main concern.
I am maintaining a set of process diagrams in visio 2007. For viewing I save the files as HTML and publish them on a web server.
It works great but its a real pain to maintain (a paintain ;-).
I am looking for a way to do this as some kind of batch job, currently the process is:
open each file
file>save as web page
in the save as web page dialogue:
select location
publish > open new dialogue
change title (i dont mind if i have to miss that step)
select web page to insert it into (my template)
done
The tools I have availiable are:
Visual studio 2010 express (i prefer c# but whatever)
Visio 2007(i have another laptop with visio 2010 which i can use too but the source files will be 2007 - that's not changing for the moment)
Ruby - may be easier if it doesn't require office integration.
(BTW I know about process repository in OSS 2010 and i have tested it with visio 2010 web diagrams - that works and would probably be a better option for anyone who has the choice, though its not perfect)
(batch file or command line would also be cool but i have not found a way of saving as web page from command line)
You can use Visio's COM interop API to do what you want (I think). I'd start by just recording a macro while manually doing the export, and then look at the VBA code that generates. You could then adapt that in C#, or VBScript/VB6 if you want something you can call with a command shell.
As Jon highlights, there's a whole API for using the SaveAsWeb functionality from code. I wrote a post about it a little while ago, which you can see here:
http://visualsignals.typepad.co.uk/vislog/2010/03/automating-visios-save-as-web-output.html
The post is VBA based but the .net version is very similar and there's also examples in the Visio 2010 SDK:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=12365
I am aware of of the infamous Considerations for server-side Automation of Office from Microsoft and it clearly lists products from the 2010 suite.
However, today I was made to believe by an IT ops techie that Office 2010 does not suffer from the issues mentioned in that article and can be used without issues within a server environment. I have been unable to find any reference or supporting doc that would substantiate the claim. (I will follow up with him on this, however he must have been referring to some other server side technique) My gut tells me he was smoking his socks!
Is there an Microsoft based solution for server side automation for Office 2010? If yes, can you please provide a relevant link that supports the claim.
(I am not looking for a Spreadsheet Gear, OpenXML SDK, OpenXML etc. related answer)
If he's referring to automating the Office 2010 client on the server, he continues to be wrong. If he's referring to newly available functionality on the server that automates some Office document processing, he's right. It's likely he's referring to the later and has just skimmed some marketing material and came to a conclusion in his head that Office client can now be a headless automation server or some such thing.
Office 2010 on the server side came with a number of Application Services that work with SharePoint 2010 that significantly assist with server-side processing of some Office documents and functionality. In particular:
Word Automation Services
Excel Services
InfoPath Forms Services
and Visio Services
It would seem that the techie was not that far off and there actually was some validity to his claim. I refer you to Windows HPC Server 2008 R2 which deals with High Performance Computing (so this does not apply to your run of the mill type workbooks that I guess most people deal with) . This does make sense considering the company I am working at is with the insurance sector. Note: this only works for for a High Performance Computing server
I refer you to a Microsoft techincal whitepaper
Windows HPC Server 2008 R2 now enables running multiple instances of Excel 2010 in a Windows HPC cluster, where each instance is running an independent calculation or iteration of the same workbook with a different dataset. Many complex and long-running workbooks run iteratively—that is, they perform a single calculation many times over different sets of input data. These workbooks might include intensive mathematical calculations contained in multiple worksheets, or they might contain complex Microsoft Visual Basic for Applications (VBA) functions.
...
workbooks may need to be modified to work with this solution. When Excel 2010 runs on the server, it does not support user interaction. Windows HPC Server 2008 R2 includes a comprehensive pop-up manager that can handle occasional dialog boxes and pop-up messages, but it is not designed to support interactive Excel 2010 features
There is also another doc: : Accelerating Excel 2010 with Windows HPC Server 2008 R2: Building VBA applications and workbooks for a Windows HPC Cluster which goes into detail as to how to building Excel solutions for a HPC server.
Your IT OPS techie should send you a link to any information that suggests this. You should then post the link here.
That way, we can try to get the link corrected. Office hasn't stopped being a COM-based desktop application. Do not attempt to automate it in a multithreaded (server) environment.
Your techie may be thinking of the fact that there are now web versions of some of the Office products.
I think everyone has proven your colleague has his wires crossed.
If the problem you are trying to solve is "how do I automate the generation of Word Documents?" then check out www.intelledox.com these guys have a .NET based Doc Gen engine which consumes data from anywhere, web service, XML etc to create documents.
They are then delivered somewhere like in an email, into an ECM system, SharePoint etc.
Means you can stand up an engine that creates standard letters and correspondence etc.
I am designing a shared add-in using VB.Net 2008 and VSTO that has to fire up when any MS Office App is started. It has to work for both 2002, 2003 and 2007 applications. I have managed to put together a working add-in that pops up a test message stating the version of Office and the Application name and tested this across all the apps ok.
The next part of the solution is to code the application specific code that needs to run for document auditing and corporate protective marking as well as, for example; in Excel checking that all the Add-Ins are linked to the Network Add-Ins folder.
My approach from now was going to be to late bind against the application object and set one of my typed (e.g. Excel) application object references which exist in the code to this object.
I'm still relativly new to VSTO so if I am doing something odd please can you let me know! :)
Ta.
I have completed this project and did it the way I specified using late bindig. It works lieka dream for all office apps both XP and 2007. :) I feel like I am announcing this to myself though as I didn't recieve a single answer or comment. Maybe you should have sexed up the title a bit Mas. Yeah maybe I should.