USE msdb;

SELECT
DBRestored = destination_database_name,
RestoreDate = restore_date,
SourceDB = b.database_name,
SourceFile = physical_name,
BackupDate = backup_start_date
FROM
RestoreHistory h
INNER JOIN BackupSet b
ON h.backup_set_id = b.backup_set_id
INNER JOIN BackupFile f
ON f.backup_set_id = b.backup_set_id
ORDER BY
RestoreDate

=CELL(“filename”) will return the sheet name at the end of the file’s path. For example: C:\My Documents\[PhoneNumbers.xls]Phone
You can then use crazy string magic to get the sheetname from that information. Pretty cool hey?

I needed to get the active sheetname to do a vlookup using the sheetname and found this formula at
http://www.computing.net/answers/office/excel-sheet-name-in-cell/2868.html (thanks Google!)

I stumbled across these blog posts:  Simple Branching Strategy Part 1: Back to Basics and Simple Branching Strategy Part 2: Implementation.  I like the posts because it talks about something close to the heart for most developers.  The topic of source control and branching strategy has always spurred quite a lot of conversation and debate on my teams, but John seems very grounded and “simple” in his approach.  I’m always a fan of keeping things simple. 

The methodology John describes is how we did it on my project:

• everyone develops op the trunk
• create a branch off the trunk for each release
• create a branch for POC (proof-of-concept) work

This approached worked well.  Whenever we had to release our code we branched and did the deploy (to QA, Staging and Production) from that branch.  Bug fixes (only the real big showstoppers) were fixed in the branch for that release before we redeployed that branch.  This is where the kicker was:  the code change had to be done in the branch and the trunk.  Sometimes the trunk was not updated with the code change and this  resulted in fixed bugs re-appearing again.

This is obviously not an ideal situation.  We addressed this in a couple of ways:

• limit the number of merges between branch and trunk by only fixing the real showstoppers
• encourage discipline by reviewing the list of bugs at our daily stand up meeting to make sure that the people who fixed the bug also merged the change into the trunk

Someone on the team suggested this approach:

• create a branch for each release BEFORE we develop the features for the release
• develop in this branch
• when a feature is complete, merge that into the trunk

The goals of this approach is to have all deployments run off Trunk, and to have smaller, contained and frequent releases.

That really appeals to me.  However, we didn’t get the time to try that.  I’m considering that approach for my next project.

It’s funny how we emphasize re-using code and principles etc, but whenever we start a new project we want try new things, or change a process.  That’s life …

My Issue: 260 character limit

I adding another solution to be built and ran into an error when the source was compiled.  The build log was very clear:
”The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.”

Why?

This is a Windows issue, and there isn’t a way to get around it.  So, I needed to understand how this happens and what the options are. 

When TFS runs the command to get the source code, it gets the source to a specific folder called $(SourceDir).

Discovery

It was not so clear how the $(SourceDir) was constructed, nor where I could change things so that the path wasn’t as long.  Bing led me to articles that gave me this understanding:

• $(SourceDir) = $(BuildDir)\Sources
  You can set the “sources” part in the config file of the TFS engine on the build machine.  So, for example, you can have $(SourceDir) = $(BuildDir)\S
• $(BuildDir) = C:\Build\$(BuildDefinitionPath)
  This is set in the build agent
• $(BuildDefinitionPath) = <team project name>\<definition name>
  <team project name> is quite a big deal, and you can’t change that easily.
  <definition name> is the name of the build you are executing, and this can be changed with much less impact.  Keep in mind that you will need to have rights on TFS to administer builds if you want to rename and/or add a build definition

Example

• $(SourceDir)
  = $(BuildDir)\Sources
  = C:\Build\$(BuildDefinitionPath)\Sources
  = C:\Build\My Project\My awesome build\Sources

Options

• Change the name of the project that caused the issue
  I could not change the names of the projects that resulted in creating the long path
• Trim the $(SourceDir) of a couple of characters.
• Change the name of the team project in TFS
  Not so cool since all the workspaces are tied to this and people are used to the name
• Change the “Sources” part in the config file
  Not ideal since this will affect all the builds from other teams as well.  
• Change the name of the Build Definition
  Much less isolated change

Resolution

I solved my problem by changing the build definition name.  I only needed to trim one character, but the name changed from “On Demand QA Deployment” to “QADeploy”.

References

• TFS Top Tips #16 – Limit what you Build – Martin Woodward
• Aaron Hallberg : Team Build and 260+ Character Paths

Microsoft Press : Free ebook: Introducing Microsoft SQL Server 2008 R2

From their site:

“We’re thrilled to publish another free ebook: Introducing Microsoft SQL Server 2008 R2, by Ross Mistry and Stacia Misner!

The book contains 10 chapters and 216 pages, like so:

PART I   Database Administration

CHAPTER 1   SQL Server 2008 R2 Editions and Enhancements 3
CHAPTER 2   Multi-Server Administration 21
CHAPTER 3   Data-Tier Applications 41
CHAPTER 4   High Availability and Virtualization Enhancements 63
CHAPTER 5   Consolidation and Monitoring 85

PART II   Business Intelligence Development

CHAPTER 6   Scalable Data Warehousing 109
CHAPTER 7   Master Data Services 125
CHAPTER 8   Complex Event Processing with StreamInsight 145
CHAPTER 9   Reporting Services Enhancements 165
CHAPTER 10   Self-Service Analysis with PowerPivot 189 “

I haven’t used ORMs but usually people don’t seem overly excited to use them.  I can’t comment out of experience, but this post sounds like some good reasonable advice. 

Using an ORM sounds like committing to a relationship.  As in any relationship, when committing to it, do it well, be in it for the long haul, play off each other’s strengths and keep your eyes wide open – after all, love conquers all

1. In Visual Studio 2008, create a new WCF Service Library project.  For this example I named the project MyWcfServiceLibrary

   

2. The template creates a Class Library project with the following files:
   1. IService1.cs
      1. IService1
         interface that defines a ServiceContract with the following methods (OperationContracts):
         1. string GetData(int value)
         2. CompositeType GetDataUsingDataContract(CompositeType composite)
      2. CompositeType
         Class that defines a DataContract with the following properties (DataMembers):
         1. public bool BoolValue
         2. public string StringValue
   2. Service1.cs
      Implementation of the IService1 interface
   3. App.Config
      contains sample config entries to define the endpoints for Service1
3. Compile the project.  It should compile without any problems.

Test the WCF Service

1. Run the project.
2. The WCF Test Client tool should open
   1. A notification window should pop up telling you that the service is being hosted

      

   2. The WCF Test Client should open.
      1. Take note of the url (http://localhost:8731/Design_Time_Addresses/MyWcfServiceLibrary/Service1/mex)
      2. A config file is generated that contains the configuration settings you can use if you want to host it somewhere else (like IIS, WAS or your own application)
      3. You’ll see the Service available as IService1.  WSHttpBinding_IService1 is the name of the service as defined in the config file
3. Double click on the GetData() method in the left hand pane.  Enter a value and click on Invoke. View the results.  Rejoice.

Host the WCF Service in IIS using the Personal Webserver

1. Create a new ASP.Net Web Application in the same solution and add a reference to the project created above.  For this example I named the project MyASPWcfServiceHost. Remember to set this project as the startup project.
2. Create the file that will host the service (it’s a svc file)
   1. Add a new item and choose Text file

      

   2. Edit the file and add the following:
      <%@ServiceHost language=c# Debug="true" Service="MyWcfServiceLibrary.Service1"%>
      1. Note the namespace (MyWcfServiceLibrary) which corresponds to the namespace of the Class Library we created earlier.
   3. Set this file as the start page.
3. Update the config file to register the endpoint of the service.  Take a look at the config file generated by the WCF Test Client for some guidance when necessary.  (I used it a lot)
   1. Edit the web.config file and add the following
      <system.serviceModel>

      <services>
      <service name=”MyWcfServiceLibrary.Service1″>
      <endpoint address=”"
      binding=”wsHttpBinding”
      contract=”MyWcfServiceLibrary.IService1″ />
      </service>
      </services>

      </system.serviceModel>

Test the hosting

1. Run the application.  You should see a page like this:

   

   1. This means our service is hosted and working.
   2. If you read through the page you’ll notice that metadata sharing is not enabled.  The page is kind enough to tell us how to turn it on (if we want).

Enable metadata sharing and test again

1. Modifying the web.config file as follows
   <system.serviceModel>

   <services>
   <service name=”MyWcfServiceLibrary.Service1″ behaviorConfiguration=”MyWcfServiceLibrary.Service1Behavior”>
   <endpoint address=”"
   binding=”wsHttpBinding”
   contract=”MyWcfServiceLibrary.IService1″ />
   <endpoint address=”mex”
   binding=”mexHttpBinding”
   contract=”IMetadataExchange” />
   </service>
   </services>

   <behaviors>
   <serviceBehaviors>
   <behavior name=”MyWcfServiceLibrary.Service1Behavior”>
   <serviceMetadata httpGetEnabled=”True”/>
   <serviceDebug includeExceptionDetailInFaults=”False” />
   </behavior>
   </serviceBehaviors>
   </behaviors>

   </system.serviceModel>

2. Run the application.  You should now see a page like this:

   This page now tells us what to do and how to use the service.  Which is what we are going to do next.

Consume the hosted service

We’ll create a console application that uses our hosted service.  Fun   We can follow the advice of the test page shown above, but not now – let’s do it another way.

Create the console application

1. Create a new console application (MyConsoleClient) in the same solution.  Remember to set it as the startup project.

Create the service proxy

We’ll use Visual Studio to do the work for us instead of running the command line as mentioned in the test page shown above.

1. Right-click on References and select Add Service Reference.
2. Click on “Discover”
3. Choose the MyTestService.svc from the list (note the url) and click on OK.
   
4. The proxy class and config file are created and added to the project, as well as additional references.
   
5. In the Object Browser we see the following:
   
   1. We have the IService1 interface, as well as a definition of the CompositeType created in the service.
   2. We also have Service1Client which is what we’ll use to consume the service.

Consume the service

1. Add a reference to the proxy:
   using MyConsoleClient.ServiceReference1;
2. Copy the code provided by the test page as a starting point.
3. Use the service and display the results.
   static void Main(string[] args)
{
Service1Client client = new Service1Client();

   int myValue = 7;
   string serviceResponse = client.GetData(myValue);
   Console.WriteLine(serviceResponse);
   Console.ReadLine();

   // Always close the client.
   client.Close();
   }

4. Run the application and see our output.
   

Debugging

If you try to debug right now, you might get this message:  Unable to automatically step into the server.  The remote procedure could not be debugged.  This usually indicates that debugging has not been enabled on the server.  See help for more information.

1. The “Server” refers to the hosting server, which is the ASP host.
2. Modify the web.config file of the MyASPWcfServiceHost project to enable debugging.
   1. Modify the <compilation debug=”false”> and set it to true.
3. Run the project in debug mode again and you’ll be able to step into the actual GetData() method.  Pretty cool.