February 2008 - Posts
When creating a column in MOSS 2007, SharePoint stores the name you entered as a display name AND an internal name. The internal name is created by escaping out special character like this:
Display Name: My Column Name
Internal Name: My_%20_Column_%20_Name
Even worse, when you edit the column name and change it to something totally different, the internal name doesn't change:
Display Name: New Name
Internal Name: My_%20_Column_%20_Name
Now, at first you might think "who cares what the internal name is". When you are working with DataViews, some third party controls, and custom Webparts - you must use the internal name. The potential for confusion is enormous.
Best Practice
When creating new columns, name them without any specail characters or spaces. After the column is created, rename it with the special characters or spaces. This way the internal name is "clean":
Display Name: My Column Name
Internal Name: MyColumnName
When renaming a column, create a new column (using the best practice above), copy the data to the new column, and then delete the old column. This will eliminate any confusion down the road.
-Joe
This is mostly an advisory FYI, and probably a good reason to view log files (as most of us do not when we get "success" messages).
I am less than satisfied with the Import and Export commands in STSADM, but this is one of those problems that seems to keep popping up, causing me enough grief that I feel the need to share it.
We generally use a higher privileged account to run the SharePoint install and Farm, thus allowing it proper permissions to run STSADM commands on the servers. It is not safe to assume this user necessarily has access to all data in your web applications and site collections.
If you design and develop a site collection that you plan to export and import into a new environment, or keep for backup purposes, be aware that the account used to login and run STSADM must have at least read access to all data in your site collection. Since the farm administrator is not always set as a site collection administrator, this can definitely cause problems.
It makes complete sense from a security standpoint, but is very easy to forget when just building out your environment. When you run the export command, everything will look fine, except data (lists, listitems, sites, etc.) that your currently logged in use does not have access to will just be absent from your export.
Keep this in mind as you plan your farm.
I hope this helps,
-Ryan
I wanted to respond to a recent reader question pasted below:
"Hi There
I have created mysite page. but my picture on mysite doesn’t show up on other SP site collection on “people and groups” how can I display it ?
Regards
Aribowo"
Aribowo,
There are two potential issues that come to my mind. First, the Shared Services Provider that is attached to your My Site must also be the same SSP that is attached to your Web Application hosting the Site Collection. Why? Because profiles are stored and synced through the SSP, it is the only way to share this information across Web Applications and Site Collections.
Second, you need to make sure you wait until the next hour for synchronization to occur. When you change data on your My Site, it immediately updates the underlying profile information in the SSP, however that SSP syncs hourly with it's Web Applications to push that data out to them. Check to make sure the timer service and job is working.
I hope this helps you solve your problem!
-Ryan