spivonious said:Maddus Mattus said:*snip*
"You need to prevent your users from being able to connect to the database without the application."
Why? They can't do anything directly in the DB that they couldn't do from the app.
figuerres - one of the developers that is no longer here setup a "OneClick"-esque updating system with our main VB6 client, so updates are downloaded and installed automatically. Pretty neat actually. I definitely see the advantages of a 3+-tier architecture, but for our needs the 2-tier is working fine. All that adding another tier would do is add another server, unless I'm missing something. The app.config would make sense too, but the client has a server choice. End users don't have a logon to the development server, and the production server is chosen by default. Not the prettiest solution, but it works.
Anyway, I have no power to change these things, so back to the topic at hand!
We use a 3-tier system (client app, remoting server, and DB). The remoting server connects to the DB with a single login. Our framework marks record edits with the application-level login details of the user for auditing.
I did consider adding the option of per-user logins, but I don't actually think anyone will need or want it.
We regard the database as belonging to our customers so they have full, unfettered access; it is their data after all. They know that if they screw with the schema or the lookup data they might well break the application and that will be their own damn fault. We make sure they have a good backup process in place. We have an hourly rate for manual database repairs. This doesn't mean that accidents don't happen, but it deters casual meddling.
At least one of our customers has decades of data in their database that their sales teams mine for info. All of our customers are free to create their own reports outside of our application's reporting system. Like I said, it's their data, not ours.