Does anyone know if SharePoint stores it's version numbers inside the files for Excel files? I would assume that it does not. This is what I need: I have an Excel file stored in a SharePoint document library. The file will eventually be distributed and must be able to function offline. The file is somewhat macro-intense, and I would like to be able to log the version number of the file within the file so that if there are errors, the version number would be known or even recorded in another place. Is there a way to access the version number within VBA without accessing a web service?
You MIGHT be able to try something where on the SharePoint ItemUpdating event you update the XLSX file to reflect the version number you want. I have not tried using the OM to update the Excel document, but I have with word, not with updating a version number.
Related
I have created an Excel document-level customization in Visual Studio 2017 using Windows 7. The document provides a set of tools for charting and analyzing data that are contained in several worksheets within the document.
I would like to provide the end user multiple versions of this document without publishing each one separately. Each version differs only in the data that will be contained. All the code, classes, subs, and functions would be identical for each version. I was hoping they could
rely on the same assembly.
I tested this by publishing a document (named DocumentA) on a test PC (Windows10) and then copying an additional file (named DocumentB). Trying to open DocumentB in Excel produces the following error:
Could not load assembly "DocumentA", Version 1.0.0.0. Culture =Neutral or one of its dependencies. The System could not find the file specified.
I think I understand why this happens. However, if I save the original published document DocumentA as DocumentB1, I can open the renamed file
with no problem. Not sure why this works and the other case does not. The property settings for assembly name and location were identical for DocumentA and DocumentB.
Is there any type of work-around? Or must I publish each of these additional documents separately?
Thanks!
I would like to provide the end user multiple versions of this document without publishing each one separately.
You need to create separate document level add-ins then. Or you may consider developing a single application-level add-in instead. See Walkthrough: Create your first VSTO Add-in for Excel for more information.
With newly released Webi there's no way to manipulate reports with VBA like it was in DESKI era.
I'd like to know if there's a way for me to click a button with parameters in Excel sheet and get a report from the server?
I've been thinking of using the RESTful Web-services but it seems that there is a performance problem.
I also considered using a JAVA app in the middle using the SDK but it's not really satisfying as I add one layer.
Do you know if there's an other way to download a Webi report from and to Excel?
For this type of requirement, you'd normally use the OpenDocument feature. There is one thing that it won't do however, at least not for Webi documents, and that is deliver the output in Excel format (HTML and PDF are the two possible formats for Webi). In all fairness, the export to Excel option is only about two or three clicks away, but I can understand that this wouldn't be an ideal solution.
Another option is the Java SDK, which I would not recommend, as the ReBEAN SDK (the part of the Java SDK you need to interface with Webi documents) is deprecated and replaced by the REST SDK.
The REST SDK would be the way to go if the OpenDocument feature is not sufficient. Keep in mind that this would involve quite a few steps, each time sending a command to the WACS server and then decoding the answer. The steps would be:
Authenticate and get a logon token
Refresh the document (if necessary pass prompt values)
Export the document to Excel
Close the document
The REST interface is only supported on the WACS server, which should run on your BI4 server (unless you have a customised landscape). If it's slow, I would suggest looking into the root cause of this performance issue, instead of discarding the SDK altogether.
If you're going to use the REST interface, I would recommend opting for JSON to communicate through REST instead of XML. It's easier to read and parse.
A last option, which I wouldn't recommend, is LiveOffice. This is a separate product which allows you to embed contents from Webi documents into Office documents (most notably Excel). LiveOffice has always had its share of problems and has not received much love from SAP regarding much needed updates.
One final thought: the report will never appear in the same sheet, at least not without an additional amount of coding. Whatever SDK you end up choosing, you will always end up with an Excel file. If you want to show the results in the Excel file you started from, you'll need to code the steps to open the generated file, grab the contents and then copy those to your worksheet.
I have a system with an Excel spreadsheet template file which is used for invoicing. I would like the user to be able to click a button on an Xpage, which will then open the spreadsheet and enter the latest invoicing data in Excel. I don't mind if Excel is either the application on their machine or on the server, but my preference would be the application locally on their machine.
I've looked into Xagents, as I feel this is probably the answer. I know they can be used to create Excel but I have not been able to locate any mention of opening an Excel file, and entering data into specific cells.
Is this possible?
EDIT: you can use Apache POI for editing and creating Microsoft Office documents. This is a java project which gives you a handle to office documents and this can be used using java.
A good starting point can be the blog of Christian Guedemann from webgate:
http://guedebyte.wordpress.com/2012/09/17/documents-and-spreadsheets-with-xpages-building-the-kernel-part-ii/
(end of edit)
The only way I KNOW and tried to write data from Notes to Excel is exporting the data to an HTML page and setting the Content Type accordingly (e. g. as described here (there are a lot more resources available for taht):
http://www.dominoguru.com/pages/developer2010_xpagexlsexport.html
I am not sure if this is of help but it seems that this project can help you:
http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&name=ZK%20Spreadsheet%20for%20XPages
As far as I can see this project can load Excel files from XPages - and then it should also be possible to edit the files.
Besides that the only solution I can think of is a Notes Agent that is called from the XPage. This agent can then run in background and do all the excel stuff. After running, the XPage can show a link to the Excel file. Actually this is the solution I would consider to implement - but maybe others step in with better answers here.
You don't want to introduce a dependency on Excel in your application -- wouldn't work with an iPad front-end. Rather have a look at the ZK Spreadsheet, it will fulfill your needs.
However if you have to have Excel, then you need a roundtrip solution: load the Excel from an URL (probably generated by an XAgent (?) and save it back. The saving back part is the tricky one. Normal HTTP doesn't allow that. What you need there is a webDAV capable server. Watch out for a project on OpenNTF soon (just clearing IBM legal) that provides webDAV.
However the ZK Spreadsheet looks much better for your needs.
I have a sample database at the following URL --> http://www.nnsu.com/nnsusite.nsf/%24%24OpenDominoDocument.xsp?documentId=B65507CB2DE15B3286257986005F061D&action=openDocument
Download the APCC.nsf. This will allow you to create/read a new EXCEL spreadsheet and then stream the resulting file to the requesting browser. There is not need to have EXCEL or office installed on the Server.
THe examples create a new workbook, but you can also store a "template" on the server or in a notes document and use it as a starting point and then save it to a document or stream it to the requesting browser.
With Apache POI you can read/write to a spreadsheet using data from the notes document the process is initiated from.
I need to be able to download a file out of SharePoint (to send externally) that has the version number in the file name.
Is there any way to do this without custom code? If not, how would I code this?
File in SharePoint -> Specifications.doc
Downloaded file -> Specifications V99.doc
I use SharePoint 2007, but I am also interested in a 2010 solution.
Don't think it's possible out of the box. As for manual implementation I see two ways:
1) If you can use some external application (or, for example, webpart or page) to do that, just get sharepoint file as binary stream and save it with the name you want.
2) If you need it to look like standard downloading, add a new custom button to document context menu (Ribbon in SP2010) and again do whatever you want with that document when user clicks the button.
This is about as close as I think we can come at this time:
http://spversionindocs.codeplex.com/
It allows you to have a version number field in your document that is automatically updated with the version number from sharepoint.
I have a method which downloads sharepoint documents to the local disk. I use SPFile.OpenBinary() method to get physical file, but it contains all fields of a parent DocumentLibrary. Does anybody know how to clear file (doc file) from these fields? I found only way to do it using Word interop library (method described here http://maxim-dikhtyaruk.blogspot.com/2009/05/trim-sharepoints-documents.html), but it doesn't fit my requirements cause it works only when Microsoft Office is installed on the machine...
You may want to read this to understand whats going on.
I do not know if this can be turned off or not, but it happens only with Word 2007 documents (docx).
You could do any of the following to turn this off:
Create a new content type and associate it with a document library. Use this document library from now on.
Look into some Open XML library or the Open XML SDK published by Microsoft.
This isn't a bug, it's supposed to be a feature! :-) Seriously though, you need to edit the Word document programmatically to remove these additional fields completely (I think even a content type will leave some behind).
For documents prior to Word 2007, you could use a toolkit like Aspose. I almost needed to do a similar thing once and would have used this product to do it. I'm sure there are other options out there.
For Word 2007 and higher, as SharePoint Newbie says, you should be able to use the Office Open XML formats to edit the document. Here's an MSDN intro article.