Access 97 Security

[doodle]

Access 97
Windows xp

I had my database secure utilizing Access security. Problem is users of
my database are also users of another secure database. So when they
change the workgroup file, they can't access mine and when changed back
they can't access the other, etc.It is too much trouble for them to
change the workgroup file all of the time. I thought about using
Windows security, removing access security and giving read only/write
access through the network, but the .idb file is the problem.

Also, I am making constant updates to the front end when reports are
added. My tables are linked from another database. There are users all
over the company and more and more have the server mapped to other
drive letters. Which means that I have to relink the tables for them
and copy the front end over to their machine everytime I make a change
to the front end.

Any ideas would be appreciated.

doodle

 

[Roger Carlson]

The best way is to bypass the workgroup file altogether and create a
shortcut on the desktop to each database specifying the MDW file with the
/wrkgrp command line switch. For example:

"C:\Program Files\Microsoft Office\Office\Msaccess.exe"
\\Myserver\Research\SecResearch.mdb /wrkgrp \\Myserver\Research\Research.mdw

For more information on this, look at the Security FAQ. You can find a copy
here:
http://www.rogersaccesslibrary.com/knowledge.html


--
--Roger Carlson
Access Database Samples: www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

 

[doodle]

Ok, so that will open the database without switching the workgroup file
but what about the linked tables? When they access the table data, will
that also use the drive specified in the shortcut?

-doodle

 

[Joan Wild]

Access 97
Windows xp

I had my database secure utilizing Access security. Problem is users
of my database are also users of another secure database. So when they
change the workgroup file, they can't access mine and when changed
back they can't access the other, etc.It is too much trouble for them
to change the workgroup file all of the time.

You can provide a desktop shortcut, as Roger suggested, or you could secure
both the databases using one secure mdw. Then they wouldn't have to switch
back and forth. It would also make things easier should one database need
to link to the other.

Also, I am making constant updates to the front end when reports are
added. My tables are linked from another database. There are users all
over the company and more and more have the server mapped to other
drive letters. Which means that I have to relink the tables for them
and copy the front end over to their machine everytime I make a change
to the front end.

You can refresh the links and use UNC pathnames rather than relying on
mapped drives. i.e. use \\servername\share\path\... rather than J: or
whatever.

Also since you are making constant updates, you might want to consider
automating the updates to the users. See
http://www.granite.ab.ca/access/autofe.htm for an example/utility.

 

[doodle]

Thanks for the tip. It will be nice not to have to deal with all of
those updates. But is there anyway to get around the server access? For
instance, someone that is Read Only on the server and the database, is
there a way around the .idb?

 

[Roger Carlson]

This does not affect the table linking. It just tells the application which
workgroup file to use.

--
--Roger Carlson
Access Database Samples: www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L

 

[Joan Wild]

No, users need read, write, create, delete permissions on the folder on the
server. This is so the ldb can be created; otherwise others will be locked
out.

 

[dbahooker]

MDB Security is a JOKE don't use MDB for anything ever in the real
world.

with ACCESS DATA PROJECTS you can use SQL security-- a much more robust
model

 

[RoyVidar]

(e-mail address removed) wrote in message

MDB Security is a JOKE don't use MDB for anything ever in the real
world.

with ACCESS DATA PROJECTS you can use SQL security-- a much more robust
model

And they are available starting with the a97 version, which this
question relates to?

 

[Rick Brandt]

(e-mail address removed) wrote in message


And they are available starting with the a97 version, which this
question relates to?

It's doubly irrelevent because you can use SQL Server for your data and
utilize its security without using an ADP.

 

[dbahooker]

anyone that is using Access 97 should be shot.

MDB is obsolete; it was made obsolete by Access Data Projects-- which
were introducted in Office 2000.

I reccomend avoiding Access 2000 like the plague; i mean-- these
dipshits didnt even make Access 2000 work against SQL 2000 when it came
out.

And now they're doing the same thing with Access 2003.

START FUCKING TAKING ACCESS SERIOUSLY MICROSOFT

WILL THE LAST PERSON LEAVING REDMOND PLZ TURN OFF THE LIGHTS?

 

[TC]

START [expletive deleted] TAKING ACCESS SERIOUSLY MICROSOFT

Erik Rucker, Group Program Managr for Microsoft Access:

"The development team for Access 12 is about 7 times as large as
the one for Access 2003"
http://blogs.msdn.com/access/archive/2005/10/05/477549.aspx

So clearly you have no idea what you're talking about.

TC [MVP Access]

 

[dbahooker]

JUST BECAUSE ACCESS TEAM WENT FROM 2 PEOPLE TO 24 DOESN'T MEAN THAT
THEY TAKE IT SERIOUSLY

microsoft has been undercommitted to access for years and years and
years

i have a laundry list of 10 bugs in access and i'll be damned if i ever
reccomend another MS product in my life.

MS has just proven; time and time again-- that they dont give a shit
about usability; fixing bugs-- microsoft is on crack and drunk, fat and
lazy program managers aren't going to solve the problem.

it is time to SUE microsoft for selling buggy software.

When they have $60bn in the bank but they can't afford to fix these
bugs?
screw redmond in the mouth

 

[dbahooker]

and seriously
Access doesn't always mean the same thing as jet.

Erick NEVER came out and said that he was pulling the plug on ADP. I
mean-- did he _SAY_ this anywhere??

COLLATION SUPPORT?
i mean-- uh.. Sharepoint?

MAKE ACCESS _WORK RELIABLY_ REDMOND AND THEN WORRY ABOUT ADDING NEW
FEATURES.

create proc sphappy

ADP is a much much much better solution that your stupid little MDB
solutions kids
time to lose the training wheels

 

[doodle]

Okay, so to get back to the subject, I have front ends local, utility
to update, tables on the network and from what everyone is saying -
everyone that views the tables needs Write access on the server, even
the ones that will not be updating them, and there is no way around it.

Also, hooker, I use Access 97 because that is what the people that pay
me have and want me to use.

-doodle

 

[dbahooker]

doodle

then quit

access 97-- does it even protect against the latest image vulns?

-aaron

 

[dbahooker]

yes; in order to let anyone do anything with mdb you need to make them
readwrite

no way to really prevent updates.

in ADP/SQL Server?? you've got real security
u can prevent updates in sql

you can prevent people dropping tables

mdb security is a joke

 

[TC]

News Flash:

(1) Access 97 is not a virus protection product.

(2) Access 97 is not a security patch to MS Windows.

(3) There is no conceivable relationship between the current WMF
vulnerability (if that's what you're talking about), and Microsoft
Access - 97 or otherwise.

TC [MVP Access]

 

[doodle]

1. What if I had two front ends saved on the network - one for Read
only and one for people with Write permission.
2. I could setup the FE update for the read onlys to reference the read
only front end.
3. I could also setup the FE utility to copy the database with the
tables over to their computer.
4. the Read only front end would reference the local copy.
5. Then the auto update would not only update their front end but also
their tables
6. They wouldn't need write access for the server because they don't
write to the tables.
7. Each time they updated the front end, the tables would update as
well.

The only difference would be that for each version I would need to copy
the front end and change the table links to local.
Do you think that would work?

-doodle

 

[Joan Wild]

I'm not sure what the problem is giving them the necessary permissions on
the server. You can hide the backend using \\server\share$ rather than
\\server\share - that way they can't easily find it in Windows Explorer
(unless they know the path).