I am trying to insert the version number stored in SharePoint Online into my Word document - I've done the following thus far:
Activated the Library and Folder Based Retention Site Collection feature
Checked "Enable Labels" in the Information Management Policy Settings for the Document Content Type, and entered "{Version}" into the Label format field
Created a Word document in my library
Opened the document in Word, and inserted a Quick Part (Document Property > Label)
What shows up on the document is {_UIVersionString}, not the actual version number. Not sure what's going on - it seems so close.
In my test, I cannot reproduce your problem.
I can display the correct version number in the document. Below is a screenshot of my test:
This may be caused by the cache, I suggest you to clean up the cache of the SharePoint page and Office first.
You can provide your detailed screenshots, which can help us solve the problem better.
Related
Appreciate your help.
I have old lotus notes database. Even having manager access it cannot open in designer.
So, took archive of the database was able to open in designer. Now when I am trying to open code of agents, scripts, formula, etc in current lotus notes version 8.5.3.
It throws error "the design element is hidden and cannot be edited".
Please could you guide on how to view code.
You have a database with hidden design here. Unless you find the template, that it was created from, there is no way to "unhide" the design as it is only stored "Compiled" in this case.
It it possible to get back "some" of the information using a HEX- Editor on the nsf file, but this will not bring you further than you already are with your backup: You can open in designer but not see any formula (in forms or views)...
When updating a database from a template you can choose to "Hide formulas and LotusScript" and this will result in what you see.
Some vendors already hide the design of their templates to protect their intellectual property. In that case you will not find an "open" template and cannot get the code back.
Our company recently upgraded from Sharepoint 2007 to 2010 and with the upgrade it managed to break a filter on one of our sites.
The site is mostly just a dressed up document library with a custom view and has a date filter (by year, month). After the upgrade it randomly generates an error of "Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator." along with a correleation ID. The logs generated on the sharepoint server state "Failed to render field Created_x0020_Date, use default value instead".
The problem does not appear to be with the query or with the returned results until it actually tries to display the web part. Somehow the created date is not getting set? The strange thing is it works intermittently. The web part loads correctly maybe 5% of the time.
Any ideas what could have changed from 2007 to 2010?
Was the "Created_x0020_Date" column a calculated column? Was it modified in any way (such as the current date XSL hack)?
I've seen that sporadic error before and for my problem it was a time-out issue with a poor performing web part pulling from 3 different lists. We increased list throttling, and caching but it didn't help. But if it's just a standard view of the library with no custom XSL in it, then it isn't a code performance issue.
Can't you just create a new created column and copy the old data into the new column using Datasheet view in the browser?
We faced this same error both in a SharePoint 2010 and a SharePoint 2013 enviroment,
when executing an old report.
The cause was the farm XsltTransformTimeOut parameter.
We increased its value (default is 1 second) to 20 (our report lasted 10 seconds to run) and it got ok!
$farm = Get-SPFarm
$farm.XsltTransformTimeOut = 20
$farm.Update()
Hope it helps!
There whatsoever no difference between the Created Date column in SharePoint 2010 and SharePoint 2007.
The differences between the two are mainly new columns. After doing some digging I found this.
You can see the complete reference of the fields here
SharePoint 2010 Document Library Column Reference
SharePoint 2007 Document Library Column Reference
SharePoint 2007 2010 Document Library Column Difference
Now, since we know pretty much nothing of your setup and how this is built we are left to chance a bit. But assuming that guessing a bit is alright I'd say you are either missing the data in the 'Created Date' field which is possible since the field isn't required (check the documents I've linked to). Did you verify that all documents got this value set?
This field (Created Date) use the TimeCreated property to check when the document was created. So if this column isn't filled with data that usually should mean that your documents hasn't been transfered to your new installation but the reference to the document is still there.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.timecreated.aspx
Thats a bit of a chance but thats what I'd start somewhere around that.
Good luck.
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.
One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.
Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.
Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.
There is a slight difference between SPFile.Properties and SPFile.Item fields and the first one is much, much slower to call.
You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx
In SharePoint, every item is an SPListItem and its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you access SPFile.Item.Properties, you actually look at the SPListItem to which the file is attached and look at its properties from SharePoint's content database.
What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)
This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a .txt file in your SharePoint store, you will not get any SPFile.Properties back.
The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.
I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).
Jonathan
Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.
P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.
I try to open MOSS document library in spreadsheet view and when I add version of document, I see it in regular view and don't see in spreadsheet view.
When I try to export to Excel I get the same problem.
May be that the library supports versioning - in that case the document might not be displayed as it is still draft. What happens if you remove versioning?