Apr 29, 2005 01:54 AM|Richard Cox|LINK
We've moved one very large application over to MySQL, let's see about 50 tables and around 250 sprocs - and then the client didn't want it (always the case isn't it?) - that's actually when we first started to wrap our heads around the DAL layer at the time.
So many moons ago - heck less than 2 years, but feels like 10 [:|]
We've done other providers, but we haven't (nor plan to) support our applications under them - simply put even with a low or high level DAL - you're still maintaining the instructions to fetch / update / insert data across multiple database platforms. I
did have an oledb one around here somewhere, I could probably find it if I could find my desk top (too many coffee cups). I at one time looked at resolving our projects into ErWin and thus letting it create the various functions necessary across platforms
- but it simply wasn't worth the effort on a ongoing basis. Sleep is already a hobby, I didn't want to turn it into what I would consider an event.
Agreed that with most effort on your DB - you are executing CRUD based transactions, therefore any low level DAL would work - I don't think we're saying that what is implemented is not right, just at what level it's implemented at.
For instance, Access / SQL Server DNN Differences in the current DAL structures are the use of OleDbParameter and SQLHelper functions, with the minor exception of a few "on the fly generated queries" (which I think aren't there in DNN 3 now anyways).
I think the original thoughts on the differences at the time we discussed this during DNN 2 beta was the fact that the application layer has to be aware of the underlying DAL executed functions (ie: SQL code difference between what the application expects
and what the DAL executes may not match - and is not caught until runtime). I can't remember what else Ron said his initial misgivings were about our DAL - I can barely remember what I ate yesterday (besides lots of coffee) [:D]