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.
Related
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.
I'm starting a new project where we are expecting to migrate desktop based Access 2016 applications (with a lot of backend VBA and relationships between the tables) into SharePoint 2016 on-premise and very soon, SharePoint Online. From what I've been told, we'll be given site permission to a SharePoint site that we can do whatever we want with. I am hoping that with SharePoint 2016 on-premise and eventually SharePoint online means that there is a SQL Server and eventually Azure SQL Database that I can migrate the Access backend tables and queries, as I know SharePoint lists will be inadequate for this, despite the false notion that SharePoint lists are an equivalent substitute for database tables.
My concern is how to build the custom forms, perform the needed business logic, perform CRUD operations, and upload data in the form of Excel files from the SharePoint site to the backend.
I'm new to SharePoint and given that it does not support VBA, that Microsoft cut out Access Web Apps earlier this year, and they are phasing out SharePoint Designer 2013 and InfoPath, some research over the past week indicates my best options are building custom web application using ASP.NET Core and somehow deploying that to the SharePoint site and subsites that we have control over, or developing a lot of HTML, CSS, and JS to create the front-end interface. I had read about the Business Connectivity Service to get and post data to / from the SharePoint site front end and the DB backend, as well as using Javascript and AJAX calls to do CRUD operations between the database and the frontend. I looked into PowerApps and those seem insufficient, and I'm still trying to distinguish between SharePoint web parts and SharePoint add-ins.
Is any of the above even a feasible option? Could someone chime in on a better path to go about this? What technologies would I need to best go about this?
Support for moving tables from Access to SharePoint remains a choice and option.
So all of your VBA code etc. will work as before. The only real question is if you want to move your data to SharePoint tables in place of using SQL server.
SQL server tables are far faster than SharePoint tables.
However, you can certainly consider moving your tables to SharePoint. When you move your tables to SharePoint (or SQL server), then Access code, forms, reports etc. and EVEN your VBA code will work as before. What this means is that you continue to deploy the Access application to each desktop. The only difference is now your tables are on SharePoint, or SQL server.
The above choice does not result in a web based application.
So you can move the data, but your application will remain a desktop application.
If you looking to build a web based application, then Access is the wrong tool – you need to adopt something like Visual Studio.
So you can continue to use Access, and put the data tables into the cloud, or on-site SharePoint - but the application will be still desktop based.
I have used the following extensively over the last couple of years and I am happy with the experience:
Azure SQL Database as a back-end
Flow for automation and as an interface to the DB
PowerApps for forms, desktop apps and mobile apps
Excel for reporting (Get & Transform aka PowerQuery and DAX), especially for printing reports
Power BI for dashboards (limited use)
Yes, PowerApps has drawbacks, but there are a lot of realistic workarounds out there and new features/improvements are being added regularly.
I have also used SharePoint lists as data sources, but almost always then migrated to Azure SQL Database.
We have an SQL Express database with an Access 2003 front end which we can convert to Access 2010 or 2013. The database has a lot of forms, queries & tables & complex VBA code.
What is the procedure to make this web enabled so a limited number of our customers can logon and update information in the forms
Will it require VBA coding from scratch, some minor changes or I don't need to change the VBA code at all?
Please note that I am talking about access web based database which
can be hosted on SharePoint site. I am not talking about php, java or
.net bases full fledge web application. So i think a person having
expertise in MS Access can answer this question.
Thanks in advance!
I am trying to make life a little easier for several coworkers and of course ME!. We need to update a database that controls our invoicing function. This database is housed in SQL Server 2008 R2. I need to provide users with a way (based on their function) to enter information affecting the invoice. For example, John has customer interaction and sends them a pdf of a document on Monday. We need to capture that John sent Customer A a pdf on Monday and it was associated with Project 123. Simultaneously, Ann is color correcting a piece for Customer A but on Project 126. I have over 50 people working in various areas who may or may not need to enter information. My hope is to make the application generic enough that the user simply selects from drop downs tied back to the original database.
The majority of the users (80%) use Mac OS. I have donwloaded XCode and I was hoping to use this to create the application that will update the backend database.
I am new to creating this type of application. I have done this with VB and VBA but do not have access to those tools here. So if there is another tact that I should take, I am more than willing to rethink my approach.
Key points are that I need to draw information from and update a SQL 2008 database. Second, I cannot use something like Excel as a front end, since I will have multiple users accessing information simultaneously.
You're unlikely to find many examples of connecting a Mac app directly to SQL Server, because that's a rare combination. Macs, unlike Windows PCs, aren't often used in an enterprise setting, so the software ecosystem to support enterprise development is much weaker.
If you're feeling brave, there are vendors out there that sell ODBC drivers for Mac OS X, some of which connect to SQL Server. So your problem becomes finding Mac ODBC examples, which is IMHO an easier problem. Google "mac os x odbc drivers". I have not tried any of them, so I can't speak to their quality.
This is going to be a lot of work, especially since you're new to the platform. You might want to consider exposing the database as an OData source (the name of the server-side technology is "WCF Data Services"). There are OData client-side librarires for the Mac. Google "mac os x odata". This approach completely bypasses the business of ODBC drivers, at the cost of some server-side development.
http://cmsreport.com/content/2010/03/ten-content-migration-tools-sharepoint-platform is a link that shows many software that exist migrating "content" from a 2007 to 2010 platform.
Barring web farm / sql server 32 - 64 bit issues, what is that which will NOT be migrated (assuming that I do a Attach / detach database upgrade method. In place upgrade is not an option in my farm.
I have a web farm with one app server and one sql server box.
Thanks in advance
Note: I did look at other similar posts but they did not have the kind of information that I was looking for.
Have a look at the following Technet article which should give you a starting point for planning your upgrade:
http://technet.microsoft.com/en-us/library/cc303429.aspx
The article should give you an idea of what to plan ahead for and what the pros and cons for each method would be.