John,

>- Security can be reached by using COM/DCOM/COM+/remote control/ layers which shields the database from the user.>

>That presents a lot of work Walter - and this defeats the flexibility argument.

Does it? How else would you implement a n-tier strategy? Isn't this one of the arguments of using n-tier?

>And quite frankley, it is rather ineffective. The user needs access to the network share the dbf's are on.

I certainly disagree. On a web based system like the UT you don't have access to the underlying DBFs either. On a remote control solution like TS or Citrix the same. And remote control is certainly easy to implement...

>And, once that access is present, there is nothing to stop the user from copying and/or opening the data with Excel, Access, etc. Agreed, there are some elaborate measures that developers can go through to try and lock down security - but in the end, none of it comes close to what an integrated security model can achieve.

It depends on what you need. If you need ultimate security, the are still alternatives in using like described above. Yes, depending on the solution you need to do some extra work or it comes automatically with another goal you're trying to achieve. In an n-tier system it is more common to have security encapsulated into the tier than not. IOW there are very effictive ways to shield the users from the database.

>You mention DCOM above. Have you every succesfully deployed anything with DCOM? I haven't - and it was not through a lack of trying. There is a reason why MS decides to leave DCOM/COM in the dust - to diffult - to kludge at times to administer.

Yes, a security system I wrote makes use of DCOM. It has been a while ago, though. Since it indeed needs some additional work, today, I would probably look for another solution, probably just in a service running one the server.

Walter,