I have a WSS 3.0 site at a small school. The teachers are using the calendar regularly when suddenly, the events are not longer showing up in calendar view. The events are THERE (if I create an email alert, create an event, I will get a clickable link to the event, but if I view the calendar in IE, no events) Each months shows some events, but it's like the calendar gets 'full' and suddenly there are days with NOTHING.
I read some stuff from MS on increasing the limit for entries, but I don't think it applies because we're no where near 2000 events in the calendar. I've tooled around the XML files, but nothing is jumping out at me.
There were a couple of MS articles that I ran thru, but no resolution yet. Any ideas? Conversely, is there a recommended cloud service that can replace this if it's not functional?
Cheers.
Even though it's been a while, I just encountered the same issue, so I thought I'd reply with my fix.
I created a new Calendar View (using the defaults) and all the items showed up. Too simple? I thought so too. I don't don't why this happened - the original calendar and the new one both had the same values (nothing was filtered, etc.), but the new one shows all the items.
Just throwing it out there.
Are the calendar items in a standard list view, but not calendar view? Is this happening across site collections?
If so, I'd recommend rebuilding their MS Office Profile. You can do that from Control Panel>Add or Remove Programs>MS Office Professional Plus. Then select Repair. Reboot, and see if your calendar view is back to normal.
Related
I am building a directory tool that will list entries for technical support contacts and listed by its appropriate company. My end goal is to allow end users to be presented with 2 simple inputs, a drop down with the list of companies and a text input to enter the name of the technical team they would like to reach. Sharepoint has made this a nightmare.
Since my server is on MSS 3.0 I decided to use a form webpart where I have added created the 2 input (dropdown and text input). I made the parameters to point to the input and added them to the filters and finally made the webpart connection.
I was able to get as far as making a sucessful filter for the technical team but as soon as I try to filter by client the results are very sporadic and mostly incorrect. I play around with the list filter in Sharepoint designer 2007 tried to group the filters together, tried changing the AND/OR in every possible setting but no luck.
Decided to push it by creating a column named blank that basically had empty values. The idea behind that was to allow end user to leave the technical team input blank and show all entries for the company. I thought somehow it would have maybe solve my sporadic issue but instead made it more complex.
At this point I can probably live without being able to search with blank results but I need to be able to at least filter by company and technical teams. At this point any sort of help is appreciated, been at this for a few weeks and my project is due last week so I am pretty much desperate to solve this problem.
For those that may have a similar problem I have found a work around to this problem. I decided to use the ASP.net User Control and this works much better than the form webpart and provides much better results.
Here a link that I found which help me get me on the track:
http://blogs.msdn.com/b/sharepointdesigner/archive/2007/03/05/asp-net-controls-filter-the-data-view.aspx
hi I'm having troubles with the SharePoint list, I've got the list connected to a Visio, and when I'm on-premise, it update fast, I mean I change the list, click refresh in the Visio app and it's updated, but on the Visio web access from SharePoint, It takes too long, I can be pressing refresh, but its like it has a timer, every 2 or 3 minutes it updates, every change I do so far. The problem is that I need to be instant, sometimes its is instant because I luckily change the list when its about to refresh.
Is there any configuration in the server to me updates that fast?
English is not my native language, so I'm sorry
If you want your changes to be shown instantly, you can set Minimum Cache Age to zero in SharePoint:
http://technet.microsoft.com/en-us/library/ee524061.aspx
Note that default value (a few minutes) provides a better rendering performance in multiuser scenario.
Also note that this seetting does not seem to be available in SharePoint Online / Office 365 (please correct me if I am wrong).
I have a SharePoint 2010 Foundation site that has recently been upgraded from WSS 3.0. The upgrade was completed successfully with no glitches.
However, ever since I have upgraded the site I have got a problem relating to lookup fields on the NewForm.aspx (New list entry page) on some calendar lists that were existing on the site prior to the upgrade.
The issue is that I have two lookup fields, one for Client and another for Meeting Type / Location. When I am on the NewForm.aspx (new list item entry page) and I select an entry in one of the lookup fields the second doesn’t allow me to select anything and just gives me the top value in the lookup list without offering any other alternative selections like it should. These fields are just standard SharePoint Lookup fields and are not modified in any way, nor is the page. This problem does not happen on new lists I create (with more than one lookup field in them) in the site nor does it happen if I add extra lookup fields on the existing lists, it just leaves these two fields with issues.
I have used Internet Explorers debugging tools to see if there is an error in any of the JavaScript on the page but nothing is being reported as being a problem and I have also tried rendering the page in different standards in Internet Explorer to see if it is related to the browser but these do not many any difference. One thing that is apparent though is that the values for both lookup fields are being pulled in to the HTML of the page as I can see them when viewing the HTML source of the page when it has loaded and in the Developer Tools in Internet Explorer…
If anyone has any experience of things like this and could point me in the direction of a fix for this I would be very grateful...
Many thanks in advance...
Take a look at these two links. This first might be your issue and while the fix was included on August 2012 CU you still have to make a manual edit (not a true fix in my book)
http://support.microsoft.com/kb/2598273
http://support.microsoft.com/kb/2687375
I need to modify the versions.aspx page... No idea how to nor do I know if this is something I should do?!? The root problem is on the history of our document we have effective and termination dates. Termination dates are kinda of the issue as they are not reflective in version history (when you look at the versions.aspx page). They are implied... but our users would like to see the termination date show up. I figured I could calculate it but I would need to update the versions.aspx page (haven't done anything like this before -- new to sharepoint dev). Alternatively I could create a new page to show history the way they want it and disable the ECB for version history... any advice or help?
Its is not recommended to touch any pages that are used by SharePoint (that is not supported by MS). You can fall back to second option you said and go ahead and create a new Page that will do what you want, you might need to do JavaScript hack to make the ECB point to the new URL.
We had a need for a document management solution and were hoping SharePoint 2007 would satisfy our needs. We felt our needs were relatively simple. We needed to manage versioning, have searching capabilities, and having an approval workflow.
SharePoint handled these three aspects great out of the box.
However, we also require that the footer on the Office 2007 (Word, Excel, and PowerPoint) documents reflect the document version, last person to modify, and last modification date. These things can be done with office automation, but we have yet to find a complete solution.
We first tried to do it on the checking-in and checked-in events and followed this path for a while, however, the complication we ran into was after we made the changes to the document we had to no way of preventing the save from updating the version number. This resulted in something similar to this:
Document checked-in – the document version should be v0.1 however it is v0.2 because we save the document after the footer is replaced. If we look in the document history we there are 2 separate versions v0.1 does not have the footer v0.2 has the footer but it says v0.1 as that is the version the document was when it was replaced.
This is an unacceptable solution for us as we want the process to be completely handled on the user side so they would have full control to revert back to a version where the footer would be incorrect and not contain the correct data. When we attempted to create a custom approval/check-in workflow we found that the same problem was present. The footer is necessary so that hard-copies can be traced back to their electronic counterpart.
Another solution that was proposed to us was to build plugins for office that would handle the replacement of the footer. This is inadequate for our needs as it requires a client side deployment of our plugins which is undesirable by our clients. What we are looking for is a clean solution to this problem.
Here is a blog post which seem to be exactly the solution of your problem.
Basically they create a custom field in the document library and use event receivers to keep the current version of the document in this field.
The "trick" is that on the client side this custom field shows up as a property of the document the value of which you can easily embed into the document's contents.
I'm not sure why changing the field won't increase the version of the document, but I guess it is because you're only changing metadata, not the actual document.
They do use a little VBA script which runs on the client side, but it doesn't require any client side deployment as it is downloaded with the document. However I'm not sure if any security settings changes on the client side may be needed to allow the script to run.
Does this information need to be in the footer? A lot of the information is available within the Office 2007 application. If you click on the round button in the upper left, and select "Server", you can view the version history, a lot of the other properties are available by clicking the round button and opening the "Prepare" menu, and selecting Properties.
If this information must be displayed in the document footer I would investigate creating a custom Information Management Policy. This may be a good place to start.