Data Access Application Block Initialisation Latency

Topics: Data Access Application Block
Jul 23, 2009 at 10:30 AM
Edited Jul 23, 2009 at 10:33 AM

Dear All,

Our development team are currently developing thick client applications using VB.NET 2005 and SQL Server 2000. We're using Enterprise Library 3.1 - May 2007.

A re-occuring issue for our applications is a significant delay on the first database operation. This significantly impacts on the user experience, and sometimes results in an application timeout. We suspect the Data Access Application Block is loading on the first call.

Has anyone else encountered this issue? Is there a workaround? We're currently experimenting with "select 1" on the splash screen to force a pre-load.

Many Thanks


Jul 24, 2009 at 5:27 AM

I've never seen this. The Data Access Block (DAAB) loads just like any other .NET assembly, and it's not really that big. The first time you hit the database ADO.NET will have to start up your connection pool, but again, that's usually pretty quick, especially for a desktop application. Have you profiled your application, or run SQL Profiler to see where the time is actually going? Do you have network latency issues that would slow connection to the database? Is it just one application or lots? How long is "significant"?

I'd strongly recommend pulling out a profiler and measuring where the time is going rather than guessing.


Jul 24, 2009 at 9:33 AM

Thanks for the reply,

This is an issue which seems to affect all our applications (there are at least 3 where it's a known issue). We deploy over Citrix, but the same issue has been noted in both local development copies and the Citrix binaries.

SQL Sproc compilation has been discounted as the one off hit (even if the sprocs were compiled for the first call, they shouldn't affect any subsequent instance of the application. I'm fairly sure the applications affected use the same application architecture (ie it's been copied and modified!). Many of the globally available properties are represented by overloaded classes for startup variables, settings, etc. The DAAB implementation is in one of these classes.  The connection and database are represented as static classes that instantiate on the first database call.

I guess our next step might be to run a timer through various stages of the initialisation, and try and catch the lines which are causing a substantial hit.

I guess I could start by measuring the initial recordset return. If the hit's there, then I could move the investigation to SQL, otherwise go back to the code base.

Thanks for your help!