How to split Front end/Back end

[Gary]

Ive read that what i need to do to my DB is split the front end and back end.
But no one really explains HOW to do it. I hope it doesnt have to be done
before you design the database as i already have A LOT of time and energy
into this one. I know the "back end" has to be stored on the shared drive
and the front end is copied onto each computer but how do you go about
actually splitting the database?

 

[Chris O'C via AccessMonster.com]

Nobody explains how to do it because they use the Database Splitter Wizard to
do it for them. Tools > Database utilities > Database splitter. But use the
wizard *only* if your db file isn't secured. If it is, please post back and
I'll give you instructions on how to split it and keep both ends secured.

Chris

 

[Gary]

It isnt secured yet, but probably will be before it is finished. But seeing
as users wont have access to the tables is there a need for it to be secured?
It is a simple database but it is FDA required so it MUST be stable. I dont
want complete open access for most people. I want the ability to create a
new entry to be open, but the ability to modify current records secured to a
set list of people.

 

[Keith Wilby]

But seeing
as users wont have access to the tables is there a need for it to be
secured?

If it's not secured then how are you denying your users access to the
tables? If you've set start-up options to hide the db window then a savvy
user can hold down the shift key on opening or press F11 to unhide it.

Keith.
www.keithwilby.co.uk

 

[Gary]

Right now this is in the complete design phase. No one is using it right
now. And I know the shift key method, but as I need a group of people to
have access rights to previously entered records to modify and update them to
be the only people who have that ability, and “all users†to have the ability
to create a new record…. I was just trying to get the multi-users aspect
worked out and all of the little kinks/quarks that the database has before I
go further with the security aspect of it.

I did test the splitting of the database and it worked perfectly.
Thank you very much.

 

[Keith Wilby]

Right now this is in the complete design phase. No one is using it right
now. And I know the shift key method, but as I need a group of people to
have access rights to previously entered records to modify and update them
to
be the only people who have that ability, and “all users†to have the
ability
to create a new record…. I was just trying to get the multi-users aspect
worked out and all of the little kinks/quarks that the database has before
I
go further with the security aspect of it.

OK post back when you're ready for security. It's a pretty complex topic.
My web site has a couple of links to get you started.

I did test the splitting of the database and it worked perfectly.
Thank you very much.

Splitting's pretty straightforward, security can bite you if you're not
careful!

Keith.
www.keithwilby.co.uk

 

[Chris O'C via AccessMonster.com]

Anybody with access to the db file has access to the tables inside it. You
can add user level security to restrict viewing the tables, but it's not real
security. If you need security for social security numbers, salaries,
employee addresses and the like, store the data in SQL Server and take the
steps to make that secure.

Chris

 

[Gary]

Its not a matter of viewing the data, this data is fairly generic, but its a
matter of changing what has been entered. I need any user to be able to
create but only a few to be able to edit.

 

[Chris O'C via AccessMonster.com]

With user level security you can assign permissions to restrict some users to
inserting records, others to updating records, still others to deleting
records, and some users only get to read the records. Or you can use a
combination of these restrictions.

But these are only restrictions, not security. Anybody with the know-how can
bypass them unless you use a secure db, like SQL Server to assign permissions.


Chris

 

[Gary]

I appreciate everyone's help. I doubt that anyone here has the "know how" or
the desire to actually tamper with the info. I just wanted it safer in case
of accidents.

 

[Keith Wilby]

I appreciate everyone's help. I doubt that anyone here has the "know how"
or
the desire to actually tamper with the info. I just wanted it safer in
case
of accidents.

Then ULS will serve your purpose mightily. To crack security you'd need to
be a hacker. In my organisation that would be a sacking offence so ULS is
perfectly adequate. I suspect that ULS is used in such scenarios all over
the place.

Keith.
www.keithwilby.co.uk