Access db accessibility (permissions??)

[Cathy Finnegan]

I've inherited a visual basic (v6.0) app that uses an Access 2000 database. Supposedly the database isn't secure so it
doesn't matter who has access to it.

When I deployed the app + database my users can't open the database (W2K or XP). However, when they install the app +
database on their own personal systems they have no problems. But at work they can't get to the database. I've made
sure that Office 2000 is installed on their systems so that all the requisite components are present.

One thing I've been able to establish is that when they are given local administrator rights to their own systems the
app and the database work perfectly.

I know very little about Access; when the app was deployed the app executable and the mdb file were deployed. What
else needs to be done so that my users can use the database without having local administrator rights to their systems.
The Sys Admins are adamant about this.

I suspect that since as local administrators they can use the app + database that there's a permissions issue
somewhere, but I haven't a clue what or where to start.

any help is definitely appreciated.


TIA

cathy

 

[Alex White MCDBA MCSE]

Hi,

Office has some querks, e.g. install it on a workstation and it will not run
properly until a user with admin priv's has run one of the applications,
then all the other users can work happly in office, this is due to some
security things going on when the first person runs office, it wants to
write some registry keys etc. The test for this is,

login to a computer as a user, make sure office does not work (open access),
the logoff, login as the administrator local/domain run access does it work?

then logoff again and login as the user you first tried, does it work?

Make sure you have the latest SP's for office.

 

[TC]

It's a bit hard to say, when all you've really told us is that the
users "can't open the database".

Perhaps some code within the app itself, is trying to do something that
requires administrative priviliges; eg. writing into certain areas of
the registry?

How about explaining /why/ the users "can't open the database" & what
you actually mean by that.

HTH,
TC

 

[Guest]

The application requires no permissions of it's own. It doesn't write to the
registery in any manner. It's a vb app, the sole purpose of which is to
enter and modify data into an initialized Access database. As I said
earlier, when people take the installation cd home and install it on their
own systems there's absolutely no problem. However, when they get back into
the work environment where Sys Admins have systems locked down and the users
don't even have the permissions to install apps on their own systems they
can't get to the Access database. The first thing that happens when a user
loads the vb application is they are asked to log on with a predefined userid
& password. This doesn't happen when they are using their work systems
however on their personal systems at home eveything works correctly. This
lead me to surmise there some permissions that are set as default in Access
that are causing this to fail in a "locked down" system. The error that's
generated on an attempt to connect to the database is: error - 91: "Object
variable or with block variable not set".

I've checked to make sure my users have RWED permissions on the folder in
which the application and Access database are installed. So that's not an
issue.

 

[TC]

"Object variable or with block variable not set" is a simple
programming error. It indicates that the programmer is trying to use an
object variable, but that variable has not been set.

For example:

dim o as object
set o = createobject("access.application")
msgbox o.name

If the createobject did not return a value (for some reason), the next
line would get that error, or something similar. The programmer should
have coded a check along the following lines:

if o is nothing then 'oops, didn't work.

I'm not saying that createobject /can/ return no value, or that your vb
app /would be/ using "access.application" to access the database. That
code is just for the purpose of showing you how the error in question,
occurs.

So, my bet is, that the locked-down environment is causing a
createobject or similar statement to fail, & the vb code does not check
the success of the statement concerned. So the app trundles on, until
it tries to /use/ the unitialized object variable, at which point, the
error occurs.

If you have access to the vb sourcecode, it should be easy to find from
here.

Cheers,
TC

 

[Guest]

TC:

I really appreciate your effort. But, that doesn't solve the problem of
what/why the Access database can't be accessed in the locked down system. As
it turns out the error generated is one I trap for.... So I know where it is
happening and the program doesn't crash, it exits gracefully. The error is
occurring on an attempt to connect to the database.

Since I know so little about Access I guess my question is how do I set up
the database so that's completely open to anyone; how do I remove all
security from it?

I really do appreciate your suggestions and help.

cathy

 

[Alex White MCDBA MCSE]

Where is the database that you are trying to open, more specifically I guess
it is on a network, what server is it sitting on NT4, Windows 2000, Windows
2003. All though you have checked the permissions have you tried to create a
file in the folder where the mdb resides from one of the users computers?
Because it could be share level permissions kicking in as well (windows 2003
read-only be default).

---

Regards

Alex White MCDBA MCSE
http://www.intralan.co.uk

 

[Guest]

Alex:

This particular user's os is W2k (SP4). The Access database file,
dbMICTS.mdb, is located locally on her machine in the same folder as the app
executable.

I did have my user create a little file using notepad and save it into that
folder and then delete it. So the permissions are RWED on that folder.

The Access db was created with Access 2000.

One thing I've been wondering about.... When I created the deployment
package I didn't include an "mdw" file..... Should I?? (Don't know what an
"mdw" file is, but I've been reading about it.)

This has me baffled. I keep returning to the permissions since my app +
database work fine when my users install it on their own personal machines (
of which they are the local administrators).

 

[Alex White MCDBA MCSE]

Have you got and server in you network?

if you have not then your computers are workgrouped, security becomes a bit
of a problem in that situation.

mdw files are security files, they are thing thing that prompts you for a
password when you first login to your database. I dont think this is the
problem.

 

[Guest]

Alex:
This particular user is on a Novel network...

But, as long as the database is local my app doesn't care whether or not a
network is present.

Is there some way for me to set up the Access database so that "everyone in
the world" can use it??

I don't mind creating another deployment package with what ever will work
for the Access database. My users that don't have local admin privilages on
their systems can't use it anyway. Those that are on stand-alone systems are
merrily working away and will not need the update.

 

[TC]

But if you are getting that error, it is a programming error - whether
you've trapped for it, or not! You are using an object variable that
has not been initialized. IMHO you need to find out why that is
occurring. If it occurs in the locked-down environment, and not in the
other environments, you need to find out /why/ it occurs in the
locked-down environments. That will lead to the source of the problem.

HTH,
TC