Today I was visiting a client site doing some data mining on a third party product that they own. Ultimately we will be building reports off of their data using SQL Reporting Services. Well, as I was going through the tables, I kept seeing date fields that didn't look like a normal date field. Much to my dismay, this third party company (who uses SQL Server 2000 as a back end database) doesn't believe that the SQL DateTime field is appropriate for storing dates. No, instead they use a long integer data type and store the date as YYYYMMDD.

Not to be out-done, they did this for times too... HHMMSS, ohh, and sometimes they combined the 2 fields... YYYYMMDDHHMMSS... is that not a mess or what. So, for us to do any date comparisons for reporting services, we have to build a view and in that view convert those crappy long integer fields into proper date time fields, well except for when their not NULL!

I just ran across a great ASP.NET 2.0 Resource Blog by Fredrik Normen. The stuff he posts is just amazing, make sure to check it out.

Subscribed!

Not sure how to report this, so I figured this would be a great way to do it...

The "Creating a Console..." and "Creating a Windows..." links under the C# Express "Learn How to Program" are directing you to a "labprod" server instead of "lab.msdn.microsoft.com".

To everyone else, if you replace "labprod" with "lab.msdn.microsoft.com" you can get to the pages successfully. I don't think any of the other pages have this problem.

The past few days I decided that my bug tracking component that I created for WebDeploy needed an overhaul. It was built directly to interface with FogBUGZ, and didn't allow for support of any other method. Alas, I thought the provider model could come in extremely handy - and it did.

Now, before you go off saying that Microsoft already created an Exception Handling Block that does almost what I did, I want to say that this was done in response to bug tracking specifically. It has a namespace structure of ErrorHandling, however that is just for future additions. Currently it only supports "Tracking."

So, what's this all about? Well, I'm releasing my ErrorHandling block that allows you to easily implement bug collecting into any application in any method using custom tracking providers. The current version comes with 3 tracking providers:

• FogBUGZ (using scoutSubmit.asp)
• Email
• EventLog

To use it, it's as simple as calling:

eWorld.ErrorHandling.Tracking.Submit("Subject", "Body", "Creator Name", "Creator Email", true);

However, its not just that simple - a custom configuration section needs to be declared to allow the different tracking providers to be loaded. A sample configuration file comes with the download, but here's a summary of what the custom configuration section needs to look like:

<bugTracking>
  <trackers defaultProvider="FogBUGZ" enabled="true">
    <clear />
    <add 
         name="FogBUGZ"
         type="eWorld.ErrorHandling.Providers.FogBugzTrackingProvider, eWorld.ErrorHandling"
         url="http://www.yourserver/FogBUGZ/scoutSubmit.asp"
         user="<User>"
         project="<Project>"
         area="<Area>" />
    <add
         name="Email"
         type="eWorld.ErrorHandling.Providers.EmailTrackingProvider, eWorld.ErrorHandling"
         sendTo="<Email>"
         smtpServer="<SMTPServer>" />
    <add
         name="EventLog"
         type="eWorld.ErrorHandling.Providers.EventLogTrackingProvider, eWorld.ErrorHandling"
         eventLog="<EventLog>"
         source="<Source>" />
  </trackers>
</bugTracking>

Simple enough, right? Okay - so download the ErrorHandling block here, and make sure you keep an eye out for any new enhancements. If you've created another provider that you feel would be worthwhile to release, please submit it to me, and I'll see what I can do.

After reading Early Adopter's post about how VSTS will not even be available via MSDN Universal Subscribers, I thought to myself - why the heck is Microsoft even implementing VSTS. If its not going to be available to most developers out there (unless your a super corp with loads of $$, not my company - we get ours from MSDN Universal) then the darn thing 1) isn't going to be bought by individuals/developers, 2) isn't going to be an available tool that MS will probably market it as, 3) isn't going to be worth the time spending thousands of hours developing it.

So my only irk about this is, why the heck create it, if you're not going to let developers/teams use it at a reasonable cost. Stupid position MS, stupid.

So I've had a bit of time to think about the new DataSources objects that are in ASP.NET 2.0, and I think I've come to the conclusion that ultimately they'll be more cumbersome than helpful. I state this in reference to how a lot of my applications are built, in which each page will have a TON of data access to do, all requiring their own business object to be called.

While the concept of using DataSources is very cool and easy to use when creating simplistic web applications, its going to be more cumbersome for more advanced applications. Now, why would it be cumbersome? Well, its taking the whole separation of code and design back to the old days, where its mixed together.  With the advent of .NET 1.0, we had a distinct separation, but it seems this distinction line is fading extremely fast in lue of Visual Studio 2005.

It is also going to be more cumbersome because instead of having distinct areas for server controls, and having your data binding methods in code, you're going to be adding more overhead to the HTML structure of a webform. So, instead of just having (in HTML):

Drop Down List 1: <asp:DropDownList runat="server" id="ddl1" />
<br>
Drop Down List 2: <asp:DropDownList runat="server" id="ddl2" />

you now have more HTML to write, which can be confusing to designers or newbies. In fact, I'm an advanced developer and I still get confused with all the extra HTML that is required:

Drop Down List 1: <asp:DropDownList runat="server" id="ddl1"  DataSourceID="..." />
<asp:SqlDataSource runat="server" ..... />
<br>
Drop Down List 2: <asp:DropDownList runat="server" id="ddl2" DataSourceID="..." />
<asp:SqlDataSource runat="server" ..... />

Sure, this isn't as complicated, because its simplistic. Imagine needing 15 drop down lists, all coming from different data sources, as well as binding a datagrid, and some detail information. That can amount to about 17 of those DataSource items, on top of your regular HTML. Now imaging that being step 1 of a wizard type UI, and having the same type of step 5 more times. Do you see what I'm getting at now?

So, is there any way of using these DataSource controls with regular HTML markup? Maybe, but I would have to propose a section that you define in your HTML page so that everything is contained in 1 place for ease. Other than that, I think I will be ultimately dreading using DataSources for future projects because of this primary problem.

What is your favorite Whidbey DataSource. Mine happens to be the ObjectDataSource because most of what I do revolves around writing business logic components that ultimately retrieves and processes the data for me. With the advent of Generics in .NET 2.0, this is seemingly getting easier to do because you can pass back a List<T> instead of just a plain old DataSet. What's yours and why? Do we need more DataSources out of the box?

Update: Eric responds to the speculations and states that Hatteras is more on the lines to compete with ClearCase and not Vault.

So word is spreading like wildfire about "Microsoft Visual Studio 2005 Team System," and it's sounding better and better with each post that comes up. However, much was overlooked and briefly mentioned concerning the VSS replacement, "Hatteras".

Korby had a great explanation of it:

"Hatteras is a spicy new SQL Server-based, fully transactional, client-server source control system that will blow your socks off."

Thats awesome, though its starting to sound a bit like a product currently out on the market -- Vault from SourceGear. It's funny also because I remember back to Eric's post long long ago submitting an application for Vault being the VSS replacement. Things that make you go hmmm....

Now, I'm sure SourceGear didn't sell their rights to Vault, I don't know why they would, unless MS paid them a hefty amount. Though, by the sounds of it, "Hatteras" may shape up to be a Vault contender when all is said and done. I get to meet Eric next week (he's speaking at our UG meeting), so I'll definately have to chat with him about this.