I've got it working now.

"Alan Questell" <alanq@pinehurst.net> wrote in message
news:82B98F1E-CD1C-46B7-A071-D41268E94106@news.elevatesoft.com...
>> Why do you say this ?  None of the paths in EDB are hard-coded - they all
>> can be modified easily at runtime just like DBISAM.
>

Alan


Its hard work until your brain accepts the new approach isn't it

Roy Lambert

Tim

Somewhat off thread but I'm interested in your's and others  views.


Users I can sort of see a use for but I'm still working on who wants roles. I've implemented a much finer granularity down at the app level. Bearing in mind that these sit above the database level (and hence probably above the app level) do people actually use these and if so how?

Roy Lambert

Roy,

By assigning rights to a Role, any user you add to that Role inherits
the rights of the Role.  When you have to define 25-50 users, all of
which have the same rights, you will immediately love Roles.


>Tim
>
>Somewhat off thread but I'm interested in your's and others  views.
>
>
>Users I can sort of see a use for but I'm still working on who wants roles. I've implemented a much finer granularity down at the app level. Bearing in mind that these sit above the database level (and hence probably above the app level) do people actually use these and if so how?
>
>Roy Lambert

Bill


>By assigning rights to a Role, any user you add to that Role inherits
>the rights of the Role. When you have to define 25-50 users, all of
>which have the same rights, you will immediately love Roles.

Its not the concept I wonder about (I do the same in some of my apps) but rather the level and the rights I can assign. Mine are more of the type

This role is allowed to use the unvalidated input screen
This person can use the validated input screen
This person is allowed to alter the sender name on an email

and may well be complicated by the fact that if someone has two different databases for the app (eg different market sectors) then a users role may well differ between the two.

Roy Lambert

Yeah, but I've now successfully migrated one complete application, so things
are falling into place.

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:6370D602-5F45-43E6-8668-0CA1C82E4E75@news.elevatesoft.com...
> Alan
>
>
> Its hard work until your brain accepts the new approach isn't it
>
> Roy Lambert
>

Roy,

<< Users I can sort of see a use for but I'm still working on who wants
roles. I've implemented a much finer granularity down at the app level.
Bearing in mind that these sit above the database level (and hence probably
above the app level) do people actually use these and if so how? >>

The fact that you've implemented security in your application is irrelevant.
The issue is making sure that access to the database is secured.  How else
would you handle security for ODBC or .NET data provider access ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>The fact that you've implemented security in your application is irrelevant.
>The issue is making sure that access to the database is secured. How else
>would you handle security for ODBC or .NET data provider access ?

NOTE. I'm NOT being facetious but why should I?

Roy Lambert

Roy,

<< NOTE. I'm NOT being facetious but why should I? >>

Why should you *what* ?  Implement security in your database ?  It isn't a
matter of *should*, it's a matter of *can* if you need to.  Just because you
don't need it now does not necessarily mean that you never will, or that no
other EDB customer will.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

I deal with a lot of hospitals and patient records.  I *have* to
protect the databases, period.  Even if my application has all the
stop gaps plugged I need to protect the data from external
(non-application specific) access.

Roles allow me to easily set up database rights that are enforceable
at the database level and prevents John Doe from using someone elses
tools to do something he doesn't have the rights to do.  I cannot
always guarentee that he will always use my application.

Case in point, I worked for a consulting company that also had a
computer store.  They were constantly coming up short in the store,
either with money or inventory.  

We finally discovered why when a customer brought a computer back to
be worked on and there was no record of the sale.  He gave us a copy
of his receipt and it clearly showed where we sold him the computer.
After a bit of investigation, we found that the salesman was using the
software to generate the sale but he couldn't delete the data after
the sale - that took manager approval.  However, he was smart enough
and knew how to get to the database and would simply get into the
database and delete the data from there.  

I won't go into how we caught him but we did red handed.  Needless to
say, we immediately decided to write our own POS system with proper
database protection since our best determination was that we lost well
over 100K to this employee.


>Tim
>
>
>>The fact that you've implemented security in your application is irrelevant.
>>The issue is making sure that access to the database is secured. How else
>>would you handle security for ODBC or .NET data provider access ?
>
>NOTE. I'm NOT being facetious but why should I?
>
>Roy Lambert