I was working on a BCS project via Web Services (more in other posts) when I ran across a frustrating dead end. When I clicked on the "Edit" for an External List I got a modal popup informing me that there was an error. It was the standard notification that advices you to change the customerrors setting in web.config to "RemoteOnly" or to "Off".

Since this was a dev machine I went into the web.config file for the site under is subfolder (...\inetpub\wwwroot\wss\VirtualDirectories\80) and set the customerrors line to "Off". I reloaded the site and tried again.

DOH!!!

I dug around, using different tools, trying to finding different means to find out what was wrong, but ultimately I wanted to know why my customerrors setting was not sticking. Luckily for me (and you) there are bright people out there and Greg Galipeau discusses this in his post at http://www.greggalipeau.com/2010/11/01/sharepoint-2010-customerrors-mode/

The long and the short is that there are TWO web.configs. It appears that the _layouts subdirectory (this form is located in "../_layouts/listform.aspx") has ITS web.config, which only actually changes a handful of things. One of them, however, is customerrors...

It is located at \Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS (ie within the "14-hive"). Changing the setting in that web.config to <customErrors mode="Off" /> caused the issue to successfully appear in the Modal popup, in this case an issue with the Edit Form:

You should especially pay attention to the fact that modifying the website's web.config (vs the Layouts folder) will have no effect upon the popups. The web.config settings in the LAYOUTS folder will OVERRIDE the settings in your website. If the Layouts has customerrors mode="off" and your website has customerrors mode="on", the _layouts will still display the error.

You could remove that line from the web.config in the Layouts folder, and then it would inherit the settings from your site, but don't tell anyone I suggested it...

Hope that helps...

One of the many nice things about the current iterations of SQL since s05 is the inclusion of Common Table Expressions (CTE). A CTE is a 'derived table', which means that it can replace the temporary tables that we have used on occasion as well as functioning as a temporary View. Because these are restricted to the query you do not have to worry about their existence once the query is gone.

One of my favorite tricks with a CTE is to use it for a list of weeks, which I can then join with tables that have dates to sort them. This allows me to do an outer join and include weeks that have no data in the physical table itself. I wish I could point you to the discussion that stirred this idea, but I cannot find it anymore...

Example:

DECLARE @startDate DateTime = '9/1/10'
DECLARE @endDate DateTime = '8/31/11'
   
DECLARE @startOfWeek DateTime = DATEADD(day, -(Datepart(dw, @startDate) - 1), @startDate)

With Weeks (StartOfWeek, EndOfWeek, weekNumber, yearFor) AS
( select
    @startOfWeek as StartOfWeek,
    DATEADD(DAY, 6, @startOfWeek) as EndOfWeek,
    DATEPART(WEEK, @startOfWeek),
    DATEPART(YEAR, @startOfWeek)
  UNION ALL
  select
    DATEADD(DAY, 7, StartOfWeek),
    DATEADD(DAY, 7, EndOfWeek),
    DATEPART(WEEK, DATEADD(day, 7, StartOfWeek)),
    DATEPART(YEAR, DATEADD(day, 7, StartOfWeek))
  from
    Weeks
  where
    EndOfWeek <= @endDate
),
BillingSummary(weekNumber, yearFor, ClientId, TotalHours) AS
( Select
    DATEPART(WEEK, DateFor) As weekNumber,
    DATEPART(YEAR, DateFor) As YearFor,
    ClientId,
    SUM(HoursBilled) AS TotalHours
  From Billing
  Where DateFor >= @startDate And DateFor <= @endDate
      Group By ClientId, DATEPART(YEAR, DateFor),DATEPART(WEEK, DateFor)
 )
  Select W.StartOfWeek, W.EndOfWeek,
    IsNull(S.ClientId,'') AS ClientId, IsNull(S.TotalHours,0) As TotalHours
   From Weeks W
    Left Outer Join BillingSummary S ON W.yearFor = S.yearFor AND W.weekNumber = S.weekNumber
    Order By W.startOfWeek Desc

Hope this helps...

LOL! In hunting down something else I stumbled across this blog entry -> http://sharepointmalarkey.wordpress.com/2010/10/12/sharepoint-internal-field-names-sharepoint-2010/ which has all the standard columns (including Title) with their GUIDs!

AWESOME!!!

Just an fyi...

Working on creating a web template system to create a designed site and ran into the above error. Found this note -> http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/27ac36ca-3d3a-47eb-9fc6-ee1b1846b8a3/

Basically you need to change the entry in the 'File' section from 'GhostableInLibrary' to 'Ghostable'

<File Url="Default.aspx" Type="Ghostable />

Due to the number of updates on this issue, I have included them at the top... below is them is the original blog...

Update: MSoft has written a vbs script to do the same as what I have listed below. The main difference is that you do not need to hunt through pending.xml - look at http://support.microsoft.com/kb/975484 for more info.

Update: MSoft has redone how WSUS rolls out w07sp1 - "Packages have been updated to address a known issue." http://support.microsoft.com/kb/894199 which might help this issue. Note that this does not appear to be a change in sp1, but in the wsus rollout format...

Update: MSoft has released Remote Adminsitration Tools that work with SP1 -> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d

Further Notes on issues with w07 sp1 in general: http://www.infoworld.com/t/microsoft-windows/what-you-need-know-about-windows-7-service-pack-1-699

Fur

Recently rolled out SP1 to our wee test group on WSUS. While it worked for most, one machine simply refused to boot, giving the BSOD (black screen of death) with "Fatal Error C0000034" as witnessed below...

Before I lay out what worked for us, let me give credit where credit is due - specifically to "thewoot" -> you can see his post here. He also mentions that you can send him money via paypal if you want to say thank you in a practical way - considering the potential costs to your organization I don't think that is a bad idea at all...

Here are his steps (with some notes of changes...)

1 - Reboot your computer with the Windows 7 disc in the drive

2 - Select "Launch Startup Repair"

3 - !!! Cancel the "repair"

4 - Click on "Don't Send" (if they don't know by now...)

5 - !!!! Click on the link "View advanced options for recovery and support"

6 - Click on the "Command Prompt" link at the bottom.

7a - fyi - if you need to get files off (just in case) you can put in a USB drive and start transferring files to it. You can either use the command prompt, or the File/Open dialog of Notepad to move the files...

8 - You are going to be looking for the pending.xml file for the installation. Please note that it might be on D: not C: because of the System partition that Windows 7 sets aside. DO NOT FREAK OUT IF YOU GO TO C:\ AND THERE IS NO WINDOWS, GO TO D: IN THIS CASE

9 - Use File/Open to browse to (either C: or D:, see above) and \windows\winsxs\. Make sure to have "All Files(*.*)" selected in the bottom right so that you can see the xml files.

10 - Make a copy of pending.xml by dragging it down in the file/open screen (just because we are paranoid)

11 - Open up pending.xml. This will take a LONG time because it is a LARGE file. Just be grateful Notepad can handle it.

12 - Do a search for 000000000000.cdf-ms. This is the section you are going to remove.

13 - Delete the section that includes it. In thewoot's directions he has you start with the <Checkpoint/> file BEFORE it and continue through to the end of the section that contains it, as he points out, the text may vary slightly... This will take a while (big file)...

<Checkpoint/>

<DeleteFile path="\SystemRoot\WinSxS\FileMaps\_0000000000000000.cdf-ms"/>

<MoveFile source="\SystemRoot\WinSxS\Temp\PendingRenames\e56db1db48d4cb0199440000b01de419._0000000000000000.cdf-ms" destination="\SystemRoot\WinSxS\FileMaps\_0000000000000000.cdf-ms"/>

14 - SAVE THE PREVIEW.XML FILE!!! This will take a while (big file)...

15 - Close notepad

16 - Exit the command prompt (type 'exit' or just close).

17 - Select Restart...

16 - It may take a bit to boot up. In our case the install 'failed' (woohoo!!!) but in other cases it might claim to 'succeed' whatever that means at this point...

So what does this all mean? I know that it is instinctual to blame MSoft, but I suspect this has to do with a 3rd party changing files. I say this because this installed fine on a number of boxes but failed on someone who does graphic design. It is quite simply impossible for MSoft to test all the various scenarios that exist in the entire world, so I am giving them some slack. As long as they fix it quickly!

What are the takeaways that I get out of it?

1. ALWAYS testbed your updates. This is a no-brainer, or should be, but sometimes admins tend to assume that simple because it works 99% of the time it will work 100% and this simply is not true. I know there is a LOT of other stuff to do, but do not blame MSoft because they cannot test EVERY SINGLE situation.
   
2. The larger the update the more testing. I installed this on a couple of boxes BEFORE I rolled it out to my testbed. Then I waited a bit. Because I was so careful I only had to repair one computer rather than who knows how many...
3. Have a beer... there are far greater catastrophes happening even as you read this, be grateful that this is not one of them...

Recently a client tried to use a program I wrote years ago on their new 64-bit Windows 7 box. It popped up the error "The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine." After some quick digging I discovered that the issue is that issue is that the 64-bit version of windows does not like the 32-bit version of the Jet Database...

My solution was to simply repackage the product to have the Platform Target be x86 (see image below) in the properties for the program. This allowed it to run on Windows 7 with no error.

Please note that if there are other things that can trigger this - esp running an app in IIS - look at http://blog.nkadesign.com/2008/windows-2008-the-microsoftjetoledb40-provider-is-not-registered-on-the-local-machine/ if this is not the issue...

Happy coding...

You ever want to set your Login system to automatically unlock users after a set period of time? Well, now you can...

I wish I could take all the credit for this, but I can't...

:)

I snagged this from http://www.aspnettutorials.com/tutorials/controls/lock-unlock-user-asp4-csharp.aspx. The only variation I made was to use an AppSetting to store the number of minutes to wait and then use that to determine the length.

In Web.Config

  <appSettings>
    <!-- Enter in the number of minutes to lock out an account. -1 means do not unlock except manually by administrator -->
    <add key="PasswordLockoutMinutes" value="15"/>
  </appSettings>

In Global.asax (to set the Application Variable)

    void Application_Start(object sender, EventArgs e)
    {
        int _minutesToLockout = -1; // default is no unlocking
        string _passwordLockoutMinutes = ConfigurationManager.AppSettings["PasswordLockoutMinutes"];
        Int32.TryParse(_passwordLockoutMinutes, out _minutesToLockout);
        Application["PasswordLockoutMinutes"] = _minutesToLockout;
    }

On my login usercontrol

     <asp:Login ID="uxLogin" runat="server" OnLoggingIn="uxLogin_LoggingIn" .../>

In my codebehind for the login control

   protected void uxLogin_LoggingIn(object sender, LoginCancelEventArgs e)
    {
        Login _login = (Login)sender;

        // unlock if appropriate
        MembershipUser _user = Membership.GetUser(_login.UserName);
        if (_user != null && _user.IsLockedOut)
        {
            int _minutesToLockout = (int)Application["PasswordLockoutMinutes"];

            if (_minutesToLockout > -1)
            {
                int _remainingLockMinutes =
                    Convert.ToInt32(Math.Floor(_user.LastLockoutDate.AddMinutes(_minutesToLockout).Subtract(DateTime.Now).TotalMinutes));
                if (_remainingLockMinutes > 0)
                {
                    _login.FailureText =
                        String.Format("You have been temporarily locked out due to too many faulty passwords. You will be unlocked automatically in {0} minutes.",
                        _remainingLockMinutes);
                }
                else
                {
                    _user.UnlockUser();
                }
            }
            else
            {
                _login.FailureText =
                    "You have been locked out due to too many faulty passwords. Please use the contact the administrator to unlock your account.";
            }
        }

    }

Hope that helps...

This is just a quick post for those of you who want a simple way to dig through the GAC to snag an assembly for your coding. I was inspired by this post while creating a website that needed to populate a series of Stored Procedures. Rather than load each one individually, I wanted a simple way to store them all in one text file which I could then access.

So I wanted to use Microsoft.SqlServer.SMOExtended. So I needed to get into my GAC (since I already had sql08 installed).

You probably know that your GAC is actually your %windir%\assembly folder (ex c:\windows\assembly). And there are undoubtedly a number of nice utilities for extracting the particular file you want, but I tend to be too impatient for that.

My solution is simply to open up a cmd prompt and go get that file. Each file is stored in a subdirectory that references its base identity (at least that is what I call it), then its namespace, then its version level. Something like %windir%\assembly\%base identity%\%namespace%\%version%\%filename%.dll

I still like to use attrib /s to look for files quickly from the cmd prompt - so this is what I did...

I could then snag that dll from the root of C: and add it to my project.

I should note (of course) that these particular dlls can be gotten much easier by simply going into the SDK subfolder of the Sql Server install... <g>

Hope that helps...

;)

I have just upgraded my desktop, and so decided to install Office 2010 (why not?) rather than keep the old Office 2007 I had. This is especially important because InfoPath forms on Sharepoint 2010 are in InfoPath 2010. And of course, more the fool me, I decided to go 64-bit. After all - my machine is 64-bit; Sharepoint 2010 is 64-bit - why wouldn't I?

The answer is in the error message below, which I received when I tried to open a simple SP2010 List in Datasheet view

This is triggered, so I gather, from the fact that my Office 2010 is 64-bit, and Sharepoint 2010, although being a 64-bit version, only talks 32-bit to its clients.

Now before you pull out your hair and go on a rant about how STUPID Microsoft appears to be in doing this, Let me assure you there is a simple workaround. You simply need to install the "2007 Office System Driver: Data Connectivity Components". You can get that at http://www.microsoft.com/downloads/details.aspx?familyid=7554F536-8C28-4598-9B72-EF94E038C891.

If you still want something to rant over - read the KB article that suggests this at http://support.microsoft.com/kb/2266203, specifically the part (and I quote) "...we recommend that you uninstall the 64-bit version of Office 2010 and install the 32-bit version of Office 2010."

I have been very impressed with Sharepoint 2010 and am busy coding my little heart out, but THIS is just plain dumb...