Blasted by SoBig

I am on the road this week and I am suffering terribly at the hands of the SoBig email virus. Due to the fact my personal email has been so widely distributed with the DotNetNuke code base, it is showing up as either the sender or recipient in a massive ammount of messages infected with this nasty bug. I am forced to use web-based mail on the road and every time I try to manage my email I have another couple hundred emails in my Inbox to sort through.

I am working away on my Access Data Provider. Turns out my automated SQL Server stored procedure to MS Access stored procedure utility did not do such a great job ( it was maybe 25% successful ). Getting deeper into the JET SQL literature I now see that it does not support batch queries or local variables. So any SQL stored procedure which contains business logic needs to be rewritten in Access so that they are simple atomic queries with the business logic in VB.NET. Which raised an interesting architectural point.

SQL Server, due to its rich Transact-SQL language, allows you to embed business logic in your data access layer. But is this really good practice? You may obtain some performance gain but from what I have read, SQL Server is not able to optimize query plans if they contain extensive decision logic. And shouldn't the business logic be done in the Business Logic Layer ( BLL ) anyways - that is the point of n-tier design, isn't it? This whole Access Data Provider has caused me to poke holes in the current design which will hopefully result in a more robust, maintainable product.