I just wanted to highlight a blog post that I found to be interesting.  It deals with a topic that I’ve struggled with as our company begins to sell SharePoint solutions to our clients.

http://wss.made4the.net/archive/2008/11/25/where-to-draw-the-line-between-sharepoint-customisation-and-sharepoint-development.aspx

I don’t work much with older versions of SQL server, but I came across the following error today when trying to disable a scheduled SQL 2000 job while trying to backup a SharePoint Portal Server 2003 database.

Error 14274: Cannot delete a job that originated from an MSX server

This error message has two possible causes: either

1. the SQL server is not a standalone server, and this message is appropriate, or
2. the name of the SQL server has changed since the scheduled job was created.

In my case, the scheduled job had been around for over 6 years, and the server had been renamed about 5 years ago.  The job has continued to run and noone needed to make changes to it.

I looked in the sysjobs table in the msdb database and noticed that in the originating_server field, the old server name was still there.  I updated each of them with the following statement:

UPDATE sysjobs SET originating_server='yourNewServerName'

and all was well.

We were getting this error on one of our SharePoint sites, and I found this helpful post in a Google search.  I have linked to it here for reference.

http://cregan.wordpress.com/2006/10/20/moss-2007-sharedserviceprovider-cannot-complete-this-action-error/

We have a server that we installed SharePoint on to use for our new production intranet site.  We needed the site to be accessible from a friendly name.  We installed it on a server with the name of prod05 (not the real name, just an example).  We wanted users to be able to use the url http://portal/ to access the site and not have to type http://prod05/.  The first thought would be to set up a DNS alias.  That is easy, but SharePoint refuses to serve the site when the more friendly URL is used.  The solution is to use the “Alternate Access Mappings” feature of WSS 3.0.

Head to Central Administration > Operations.  Under the Global Configuration section, click Alternate Access Mappings.  You will see an entry for http://prod05 (Zone: Default).  Click Add Internal Urls at the top.  Click the drop down next to “Alternate Access Mapping Collection:” and choose the main SharePoint site.  Enter the friendly name into the “URL protocol, host and port” box. (In our case: http://portal)  Make sure you choose Extranet as the Zone.  This is the crucial part.  Leaving the zone as Default will allow SharePoint to serve up the page to that URL, but it will redirect the user’s browser to the unfriendly name.

Suppose you have a form named frmMain (Main) and a form named frmInformation (Information).  You want to open the frmInformation from frmMain as a modeless window (so the user can return to frmMain) but prevent the window from being opened again and having two copies of the Information window open.

On the button click or whichever trigger you choose in frmMain, use similar code to this:

// check to see if frmInformation is already open
if (Application.OpenForms["frmInformation"] == null)
{
     // it is not already open, so lets open it and show it.
     frmInformation informationForm = new frmInformation();
     informationForm.Show();
}
else
{
     // it was already open, so bring it into focus.
     Application.OpenForms["frmInformation"].Focus();
}

I took the following pictures of mammatus clouds a few weeks ago on my cell phone after a thunderstorm passed close to Conway, AR.  I’ve never seen these type of clouds before, and I had to go look them up to see what they were.

While working today I came across a perceived problem with using Visual Inheritance (Windows Forms that inherit from “base” forms).  Microsoft has admitted that it is an unsupported scenario:

“Modifying collections, such as the columns in a DataGridView, in inherited forms or controls is currently an unsupported scenario.”
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=284335&wa=wsignin1.0

Fortunately, there is a workaround that seems to fix the problems I have with it.

Create a user control class, and paste the following code:

[Designer(typeof System.Windows.Forms.Design.ControlDesigner))]
public class ucInheritedDataGridView : DataGridView { }

Now refer to ucInheritedDataGridView every where you would have an inherited DataGridView.

OK, well I’m sure this is documented hundreds of other places, but I am mainly putting it here for my reference.  If you want to post source code on a WordPress blog, surround your code with the following tags (making sure to replace lang with the supported language code:

[/sourcecode]

If you create a new form and change its type to inherit from DevExpress.XtraEditors.XtraForm, the entire form will take on the current Default Look and Feel of the application. To make the title bar and window border also take on this theme, you must add the following line somewhere early in your code:

DevExpress.Skins.SkinManager.EnableFormSkins();

I recently discovered that when creating a child MDI form that has the XtraForm base type, it still does not take on the default theme.

The fix for this is to use the following code in the child form:

protected override bool GetAllowSkin()
{
     if (this.DesignMode) return false;
     return true;
}