>Are you kidding? We've been through this before. My classes have no idea what a field is! They don't even know how to spell SQL. All of my database "info" is in custom properties.

OK, that's good ... I just wonder then why you asked if data access and connection to SQL was the same.

>And there is definately a place for direct and specific data access code in the user interface, when you need to override the ordinary operations and make a form specific for a client.

But yet a Form can be specific for a customer without having the DataAccess code in it. I don't understand you on this. You call out to a DataAccess layer. It's a class in a different DLL ... easily swappable, if need be, for different customers.

>In your model, how do you customize specific data code for one customer? Do you give them a separate EXE? Please let me know!

Different EXEs? Heck no ... our EXE is a very, very, VERY small portion of out entire app. Just about everthing is loaded via reflection, so by having different stuff in different DLLs, it's easily customizable. In fact, we have a methodology whereby we can aggregate several different applications "under one roof" so to speak (they would each have their own EXE, again a small thing, but clicking on any one EXE still allows the user to see modules from any of them, if they have the proper rights defined in metadata in the database). The only thing these different apps have in common is that they all use the same "Framework", which is built to handle this "aggregation" seamlessly.

Yes, people all do things differently, I agree ... but I still believe in layers and the DataAccess should be in a different layer (project/DLL) from the UI.

~~Bonnie