June 2010 - Posts
Did you know that when you're working on custom Edit form and add an extra field via the Columns command, SharePoint Designer will sometimes add the field in Insert mode instead of Update mode? Yes, it will. Sometimes. The binding portion of the field should look like this:
...but instead, it looks like this:
That little "i" will make all the difference in the world. You'll chase that form all over town, wondering why it's not showing the current price of eggs in the country of your choice, because it's certainly listed correctly in the List Item... and finally you'll flip that little letter from "i" to "u" and feel really silly for wasting all that time on something so small.
...or so I've read. You know, about people who had that happen to them. Certainly not me.
This really is no different from when you create an audience with regular old NTLM (Windows Authentication). The difference is that while the AD provider is set up by default in all environments, the extra membership provider (that you use for Forms Authentication) isn't included anywhere except in the web application where you install it. To be able to find your FBA users in the audience creation tool, you'll need to add the extra membership provider(s) to the web.config for your SSP site in IIS. At that point, the People Picker should start recognizing your Forms Auth users, and you can create your audience as needed.
If your SharePoint site collection hasn't grown, but your content database has, the most likely culprit is versioning. If a list -- or worse, a library -- has versioning enabled, the default is to keep every single one. That means that every time someone edits and checks in a document, its storage footprint increases by the size of the document (and probably a little more).
The solution? It could be a bit painful, but you'll need to go back into each library and restrict the number of versions to keep (three is sufficient for most uses, but your needs may vary). I suggest keeping only major versions as well, since minor versions are really just stopping points on the way to a published document.
Of course if you have a real business need to keep all those versions around, then you'll want to look into an archiving solution that will take the old versions out of the content database but still make them available if necessary.
Recently, a discussion broke out (go figure) on a SharePoint list that I frequent. It had grown in size to the point where the more advanced members were sometimes turned off by the volume of questions that appeared TOO simple. This happens all the time, as something becomes larger and specialization is necessary.
Anyhoo, my response was to create the SharePoint Beginners group. Come out and join us at http://groups.google.com/group/sharepointbeginners , where no question is too simple; all we ask is to show us that you tried to find the answer.
Recently, a colleague came to me with a simple task and an inscrutable error. He just wanted to populate a text field with a querystring value. If you've ever done this in SPD, you know it's fairly simple: create a parameter, map it to a querystring value, and then use the resulting parameter name in your form field.
Having done so, however, he was told the following by the ASP.NET "yellow barf page":
The 'Text' property of 'asp:TextBox' does not allow child objects.
As it turns out, he had done everything correctly. The problem was that SharePoint Designer had decided the best place for his FieldDescription control was INSIDE the TextBox control. Obviously the compiler doesn't know what to do with that. When the FieldDescription was moved to a less obtrusive location, everything worked as expected.
The moral of the story is, as always, don't trust what any WYSIWYG tool gives you. If it looks great, then fine. However, if there's a problem, remember that Design mode was written by human beings who make mistakes... just like the rest of us.
Take THAT, Skynet.