DAL rest in peace

I wrote some posts regarding the General Network error and I am still not sure to find a right answer to this important issue.

OK the only solution which seems to work pretty well is to set pooling to false in the connection string.

Yes, damn right but his has some performances consequences. So after some quick investigations, I realized that most of my projects are built using DAL (Microsoft Data Application Block v2).

This is an impressive SQL helper and I really dream to have something like that embedded in Whidbey.

After some tests it seems for me to be the culprit for all the General Network errors I can have. The weird problem here is the error show itself only in production environment with SQL server independent from the Web server.

Everything is ok on my local machine with all software required in one place.

Microsoft If I am right decided to not support anymore the DAL as it is. I know that a version 3 exist here (I think it's in GDN).

I have a look at the code and it's quite complex, as expected from MS.

So sadly I will have to abandon the joy of using the DAL, having no time to fuss with errors on production servers.

I will probably anyway writes a (basic) SQL helper for my needs based on the experience I got with the DAL. Well the not-so funny part will be to change all current DAL plumbing to the new helper.

So DAL rest in peace unless someone volunteer to debug you.

 

9 Comments

  • I've encountered intermittent general network errors on our ASP.NET project infrequently since its inception. In fact, one reason we were originally excited about the application block was the hope that by standardizing our access code we would eliminate something we were doing wrong. While we are very happy with other benefits of the switch the problem has persisted.



    Our experience suggest that the root of the problem is deeper then the access layer (either your own or the block), so you may be doing yourself a disservice by ripping it out.

  • Well to answer Baby with the water (wow some imagination there !) I performed some tests with and without DAL. And sadly I have more troubles with it.

  • Do you use a lot of DataReaders?

    Any chance that you are leaking connections?

  • I would gree with AndrewSeven. I got the same problem with DataReader. You need to make sure that you close DataReader explicitly every time.

  • Andrew yes I use a lot of datareaders.

    but most of the time, I use them in a Try Catch code and I close the reader in the Finally section to be sure that whatever happens it's really clode.

    What is strange anyway is that the pooling=false solution in the connection string is working really well. Nor more errors since. But yes surely it's not the right way.

    Difficult also to pinpoint the cause becuase .Net still has some unmanaged errors like this one.

  • And I remembered someone mentioned about .CommandTimeOut. You might need to explicitly set .CommandTimeOut to an arbitrary number which is not 0. DAAB 2.0 set it to 0 by default and it causes some unexpected problem... Try this first... it might go away.

  • DAAB 2.0 is going to continue to be supported, as I understand it.



    3.0 is a community supported version, with support for other Databases and various other enhancements (haven't tried it yet, though the ORACLE project I'm working on may warrant it at some point).



    I shudder when people talking about integrating this sort of thing into the framework.



    1) The framework is big enough as it is.

    2) You discourage developers from learning how things work.

    3) Source would not be available.

    4) The flexibility of the framework *could* be lessened by integrating application blocks.

    5) ObjectSpaces is an option for data access, as is SQLXML (in VS 2005).

    6) etc.

  • I wrote my own DAL well before the Application Blocks were available (I also needed transparent switching among SQL, Access, Oracle, and ODBC), and I ran into some of the same General Network errors. I'm also a big fan of DataReaders.



    IIRC, my problems were in fact related to connections left open. Make sure the CommandBehavior is set to automatically close the connection and make sure you Dispose your connection object (or whatever the app block equivalent is).

  • The problem with DAL it don't let add a commandbehavior in the parameters. when I look at the code it suppose to close the connection at the end of each method, reader or dataset

Comments have been disabled for this content.