This has to be done programmatically, and we opted to use Powershell to do it. Here’s the code:

#Application of a given theme to a Sharepoint site and all sites beneath it

#First, load the Microsoft.Sharepoint objects into the Powershell space
[System.Reflection.Assembly]::Load(“Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral”)

#Open the target Sharepoint site (Replace oursharepointsite with your respective URL)
$site = new-object Microsoft.SharePoint.SPSite(“https://oursharepointsite”);

#Open the top level web
$siteweb = $site.OpenWeb();

#Enumerate each subsite in the allwebs collection, and apply the chosen theme to each one
foreach ($spweb in $site.allwebs)
{
write-output ($spweb.theme + ” ” + $spweb.title);
$spweb.ApplyTheme(“YourNewTheme”);
$spweb.Update();

#Write the name of the new theme as confirmation that the change was applied
write-output ($spweb.theme + ” ” + $spweb.title);
}

#Clean up
$siteweb.Dispose();
$site.Dispose();

Depends on how your options are set. One of the things I noticed is that if you have the Lotus 123 compatibility options selected, Excel will not only unhide the hidden rows in the sheet you’re referencing, but it will also not hide them again.

It should be mentioned that this behavior is not enabled by default, but if you should run across it, here’s how to turn it off:

Click the Office Button -> Excel Options. Click the Advanced section, and scroll all the way to the bottom. Uncheck Transition navigation keys, Transition formula evaluation, and Transition formula entry.

Did you find this information useful or helpful? If so, buy me a cup of coffee.

So as part of this new database development project I’ve been working on, I’m having to normalize and unwind an unwieldly Excel sheet that’s chock full of intermixed data within the same columns. Values, ranges of values, integers, currency, percentages, and text. Yeah.

As part of the conversion process and figuring out what algorithms to write to unwind the data, I’m using the Visual Studio 2005 Business Intelligence Development Studio to run my data conversion and SQL population tasks. One of the things that’s SERIOUSLY irritated me from the get-go about this tool is that the Excel OleDBConnection object flat out ignores data, or gives its own interpretation as to what it thinks a certain column’s datatype is. (STUPID.) This ended up throwing errors that wouldn’t even output to the specified errorOutput columns – just to a dialog box that said it gave up. In short, it wasn’t able to convert from the datetimestamp datatype from Excel to the datetime datatype in SQL.

I showed this to my resident data warehouse SQL guru guy, who was having a similar issue with a project he was working on. Apparently, there’s a not-so-well-documented “feature” in the OLEDB connection string (used in BIDS) whereby if you append the value IMEX=1 to the end of it, it forces the data flow task to read all intermixed data as a string. Dates, integers, strings, whatever. (Verified by connectionstrings.com). The Data Conversion step in my workflow task FINALLY started behaving normally and doing what I asked it to to – including throwing data into the correct external columns and everything in my test table. WOOHOO!

Now the fun of trying to figure out how to un-wind the cluster of integer strings and values in my dataset. *Sigh* Any cursor gurus out there?