I'm a C++ developer wrestling with updating an application that had made extensive use of the IStorage interface to open pre-Office 2007 documents from in-memory storage (via ILockBytes).
If you are still following me so far, you probably know that the new Office Document formats are incompatible with IStorage containers. The application I'm trying to update, relied upon the IPersistStorage interface that all Office applications have, and the code as written calls the load method of IPersistStorage to read in a document from IStorage interface.
So the question is:
What kind of COM interfaces are available to me to read in, from an in memory container, an Office 2007 document?
I've been struggling with pretty much the same problem, to read and write from database storage.
Right now, I'm thinking that the best way might have to be to use the WebDAV-support, and use a web server to implement WebDAV to read from and write to the database.
It's a mess, though... other pointers would be welcome :-)
Related
I am trying to create a data entry "app" to collect daily readings across our site. Here are the three biggest constraints:
Software - ideally, we would use some software within the Microsoft 365 Suite, mainly because those are the only approved apps on site. It may be possible to use open source software, but that might raise some flags in terms of security. So my thoughts are to use either Excel or Access.
Cost - ideally, we do not want purchase any additional software licenses. I would try and create something with Power Apps, but we do not have the licensing for an Azure or SQL server to store the data. I could be missing something here though.
Mobile-Friendly - finally, it needs to work on an Android tablet. Currently, we collect readings using pen and paper. The whole idea of this is to move towards using a tablet.
The easiest approach would be to create an Excel spreadsheet, save it on OneDrive, and edit the spreadsheet. I don't love this option because we are collecting 100's of data points each day. This would end up with a very wide spreadsheet that will be cumbersome to navigate.
The other option I looked into was creating an Access database and accompanying form and storing it on SharePoint. However, it seems Microsoft has stopped supporting Access databases on SharePoint.
I have created data entry forms using VBA, similar to this, but these do not work on mobile.
Is it possible to create a data entry form in Excel that also works on the Android version of Excel? Are there other alternatives I am not thinking of?
I am engaged in just this kind of project also. I have written an app in PowerApps, built an Excel spreadsheet and stored it in OneDrive, and am running it (the app) on an iPad. The design differs somewhat from your description of directly presenting a spreadsheet to the user (which I think PowerApps could do) because I don't want users having direct access to the data.
Edit: You do not need Azure or SQL, unless you are storing tons of data. Excel can be a satisfactory data storage location for modest uses.
I found the learning curve for PowerApps to be quite steep, as it's a different paradigm than line-by-line coding.
I think this is a more user friendly way to collect data than trying to run an Excel form, and once you get it made and polished, you'll look like a pro :)
I am by no means an expert but if you need some tips I'll do what I can to help. It sounds like we are at similar developmental stages.
Is it possible to create a data entry form in Excel that also works on the Android version of Excel? Are there other alternatives I am not thinking of?
Microsoft Forms does the job when created from OneDrive on mobile browser. Side note: the form I just created and the response I submitted have now disappeared from my OneDrive.
I also saw some people using Power Automate to save responses from a form into an Excel file (every reponse).
I have read very little content regarding Sharepoint (SP), and most of my reading has been sales pitch oriented overview material. I utilitze VBA with Office apps - especially Access - on a regular basis, and I am wondering if there is any translatable way to retain the custom functionality of writing my own VBA within Sharepoint, especially with MS Access.
I have read that Access databases can be run on SP, with tbales to list and forms to InfoPath, but I am assuming they are primarily talking about Access database apps that were built with wizards, which consist mainly of bound objects without explicitly-defined code.
Most of my app are primarily code driven with VBA because of my automation requirements, which I rely on to perform my tasks. Am I going to be able to accomplish the same thing within SP, and could anyone please provide any references on the subject, specifically?
You can use Access to distribute your front end to users, regardless of how much VBA it has, but an app with VBA code in it will not convert to run in the browser as a Web Database within Sharepoint 2010's Access Services. For that to work, you have to use the new, more powerful macros and limit yourself to the features supported by web objects. For an existing app, this means rebuilding every object from scratch.
Do you need to run your Access app in a web browser? If not, then you're barking up the wrong tree here.
AFAIK Sharepoint does not support VBA.
If you publish an Access database to SharePoint as a web database it cannot use VBA, however you can create a hybrid with the tables in SharePoint and the frontend in Access, that way you can have as much VBA etc as you want and still have the advantages of your data being stored in the SharePoint SQL server. You can store the frontend on SharePoint and have users download it through SharePoint .
The alternative is to keep a traditional Access database on the SharePoint share and access it via webDAV rather than the SharePoint web interface. You could map the SharePoint library as a local drive to make it easy.
Note that drive mapping is considered a legacy technology and will no longer be supported by Windows 11 due to the demise of IE11.
What is the best way to convert Microsoft Office documents automatically on a server? We need to convert lots of such documents automatically to PDF files. Currently we use PDFCreator with an OLE script, but it is a fragile process since Microsoft Office popups keeps interrupting the flow.
I have tried OpenOffice, but it is not good enough at converting Microsoft Office documents.
We've used the Oracle OutsideIn technology (formerly known as "Stellant") to do conversions of Office documents to XML. It was 99% effective, but there was the occasional document that would confound it.
http://www.oracle.com/us/technologies/embedded/025613.htm
They appear to have a PDF Converter component, but I have not used it.
OutsideIn is pretty pricey. They are targeting the enterprise customer.
--
There's also KeyView from Autonomy, but we have not used that either. Looks like they do not have a direct to pdf option, but they do go to html directly.
http://www.autonomy.com/content/Products/idol-modules-connectors/index.en.html
Not sure what you mean by 'automatically', but try Google Documents. You can upload .doc files in bulk to be converted to google's format. From there, you can export (in bulk) to PDF.
To use Google Docs, get a gmail account (or google apps account) and go to docs.google.com
I have an issue with a new sharepoint install that we've recently deployed to replace an ageing content management system that I implemented a few years ago.
What I'd really like is to save my colleagues as much effort as possible by transferring the content from my CMS into sharepoint.
I'm not very good with sharepoint yet, and my development platform of choice is PHP MySQL, so basically I'm wondering if sharepoint has any facility to import sites, I can easily built filters to reformat the content in my CMS into whatever (please let it be XML) format sharepoint will accept but I have no idea if sharepoint will even let me do this.
I have limited access to the sharepoint server, although in this case I can probably negotiate more if that's the only way.
Mostly I just need some pointers - does sharepoint have any facility to do this, and where do I start doing it?
Thanks
SharePoint has the ability to import data from an Excel spreadsheet (Site Actions > Create > Import Spreadsheet).
The only problem you may run into with this method is that you don't necessarily have full control over what column types the importer uses for your data--if that's important, then it will take some trial and error.
If you're familiar with .NET and you can get access to run a program on the server, you can write a program to import data into existing lists using the SharePoint object model.
the fastest way to bulk import data into SharePoint is through the batchdata method
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spweb.processbatchdata.aspx
it is aimed ad importing list data, but it seems there are some workarounds to make it work with publishing pages
http://social.msdn.microsoft.com/Forums/sharepoint/en-US/f8fe190d-c1ed-4e15-bda2-7792211973cc/bulk-publishing-page-creation-using-processbatchdata?forum=sharepointdevelopmentlegacy
I want to use the Microsoft.Office.Interop to read an Excel file from a web page.
Do I need to have Office installed on my web server?
I am not doing any manipulation to the excel file, just reading it in and storing the values to another page. I have no issues when I run on my local machine but I have Excel installed on my local machine. Anyone that knows this answer I would greatly appreciate your input.
Thanks
JD
Using Interop requires that you have Office installed on the server. For websites, I would generally recommend using something like the open-source NPOI project. However, if all you ever want to do is read, consider using ADO.NET (see this question for more info).
I would add that if your using Excel as a datasource the ADO approach is much faster and requires less overhead. It restricts you to excel sheets that are pretty much structured as flat tables. But if I can use that method (all restrictions considered) I prefer it.
Ernie