Unidev .NET Technology Blog

Author Archive

by Allan Sieker

When it comes time to write an interesting article about a technical topic my mind goes into a deadlock in trying to find the balance between space/time constraints and keeping the content interesting.  Too short of an article and it seems trivial because the technical stuff doesn’t get covered enough.  Too technical, and the article becomes long and boring.  All the while, wanting to keep things original, informative, and light.  So did I end up with?  How about a series of related articles that covers something that is near and dear to all of us?   

 I bought my first computer in 1978 (yes, I still have it) and as my home network expanded to what it is now – several servers, workstations, and laptops, the need for keeping a file inventory goes with the territory.  Sure, over the years I created my own file databases written in several languages (BASIC, Pascal, dBASE, Clipper, VB, C#) and they all served their purpose, but technology keeps improving and I always want more.   

 What if data warehousing concepts were applied to capture the “slowly changing dimension” of file updates?  What if file collections were recognized and managed as applications and other entities?  What if all of the computer file inventories were gathered locally then stored centrally for searches via a web interface?   What if backup history were also available?

 This article series will cover a broad range of technical topics with the end goal being a respectable system for home or business usage.  Concepts will be discussed and code will be available for download.  References to other articles and postings will also be made.

 Here is a brief list of planned topics: 

• Using recursive methods to collect file information from all of the folders on a drive.
• Creating console and Windows “file agent” applications to collect file data and write to an XML file.
• Creating a SQL Server file inventory database.
• Balancing cost and architecture to avoid over-costing and over-engineering.
• Importing “file agent” XML into the database.
• Creating an ASP.NET web application for searching and retrieving application & file information.
• Making “file agent” applications downloadable from the web site using ClickOnce.
• Using the Visual Studio Report Designer and the ReportViewer control to create web reports.
• Creating a “wrapper” application for Microsoft’s Backup to manage and track backups.
• Detecting media and image file duplicates based on file content instead of file name.

 Feedback is always welcome.

by Allan Sieker

Just recently I had the opportunity to investigate a timeout error happening on an ASP.NET web application of a new client.   This web application is a very intense and complex business solution involving tiered hierarchies of entities for companies, resources, processes, and projects.  Definitely not your typical web site.

The source of the timeout was an embedded SQL query consisting of a SQL view joined to another table.  A SqlDataAdapter was being used to fill a DataSet from a SQL Server database.   Very straight forward on the surface, but then I noticed that the a CommandTimeout setting of 60 was being used.  Why would such a simple query be taking more than 60 seconds to execute?

My first was to set a breakpoint just before the execution of the query so I could see what the actual parameter values were.   My second step was to copy/paste the query into an open query tab on SQL Server Management Studio and alter the query to use literal values from the first step.   To my surprise, the query did take a bit of time to execute.  Time to drill down.

I scripted out the SQL view and found that it consisted of a 13 table join where 3 of the joins were to views with joins of their own.  And one of the returning columns was a function having several querys of its own – and a 3 table join.  Time to get another Diet Mt. Dew…

I now understood why the previous developer slapped in a 60 second timeout.  Sure, I could have increased the timeout to 120 seconds and it would probably have solved the problem.  But would it be the professional way of solving the problem?  I thought not.  Besides, I didn’t want to put the client through a compile/rebuild/release cycle for just changing one line of code.  Another important thing to consider is that the users will have to endure this long query several times a day.  I couldn’t take that road.

This query and all of its branches was way too complicated to digest quickly, so I started breaking each branch down and checking to see if the queries were taking advantage of indexes. 

As it turned out, in about an hour I found four places where an index could be added and the yield of that effort took the 60+ second query down to 3 seconds.  The users were  ecstatic.

So the moral of my story is this:  Please do not blindly increase the timeout values without an honest attempt to tweak the query.    The time you take this one time will benefit your users every day.

 By Allan Sieker

If you want to learn something from one of the best, please check out Clint Edmonson’s web site where you can download free coding standards for both VB and C#.  I worked with Clint at AB and I must say that he is one sharp guy.  I am sure he raised Microsoft’s collective talent a few notches when he joined them.  Be sure to look him up at the St. Louis “Day of .NET” Conference in August.

Shifting gears from .NET to SQL….

I ran across “Ten Common Database Design Mistakes” and found it to be most interesting.  I’m sure you will too.

by Allan Sieker

The story you are about to hear is true and should be of interest to all web developers – be you .NET or not.

A few businesses I know had issues with web site connectivity a few weeks ago.  Some computers could connect while others could not.  IE 8 seemed to have more of a problem than IE 7.   The client could access other web sites ok.  Client locations were across the US and not all local (the St. Louis area).
Read the rest of this entry »

by Allan Sieker

The Overview

   “We do not pretend to have achieved perfection — but we do have a system — and it works.”  – Klaatu

When developing ASP.NET web applications a very common approach to maintaining state is to store variables into the Session.

Session is just one way to store data. Here are some other ones that I know of. Can you think of any others?

• Application (global) – uses server memory.
• Session (user) – can use user memory and/or database storage.
• Data cache (global, but can be user specific with proper handling) – uses server memory.
• Viewstate (web page) – rides along with the page.  No server memory.
• Database (global and user) – includes SQL, XML, local files, etc.
• Cookie (user) – stored on the client’s computer and accessed via the browser.
• Query String (user) – doesn’t use server memory – just a lot of developer patience.
• Form fields (web page) – popular in HTML and classic ASP development.
Read the rest of this entry »