By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,664 Members | 1,970 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,664 IT Pros & Developers. It's quick & easy.

Can a lone computer have Access db problems?

P: n/a
One of the users in our departmental db has Read/Write permissions to a
particular form. He was able to access and edit the form at will until 2
weeks ago. His current problem was that he was not able to edit the data
(no message ever appeared telling him he could not change any data). The
only change to the db since he experienced the problem was that a new
version of the db was made available for installation which everyone has now
installed. (The new version did not affect the form the user accesses, nor
was his permissions changed). Both my Admin Asst and I used his user login
and password on our separate client machines to enter the db and gain access
to the form he uses. Both of us were able to edit the form (logged in as
him) with no problems, yet he is still unable to edit the form from his
computer. That, to me, would suggest that the problem lies with his
machine. The only problem with that assessment is that it doesn't make
sense that "something" could be different on his computer to not allow him
"Write" capabilities on an MS Access application. Networked computers don't
work that way (singling out certain computers to misbehave).

Running WinXP w/ MS Office Pro 2003.

Has anyone every experienced a similar malady and, if so, how was the
problem resolved?

thx for any suggestions...
Earl Anderson
Jun 27 '08 #1
Share this Question
Share on Google+
3 Replies


P: n/a
"Earl Anderson" <is*****@optonline.netwrote
One of the users in our departmental db has Read/Write permissions to a
particular form. He was able to access and edit the form at will until 2
weeks ago. His current problem was that he was not able to edit the data
(no message ever appeared telling him he could not change any data). The
only change to the db since he experienced the problem was that a new
version of the db was made available for installation which everyone has
now installed. (The new version did not affect the form the user
accesses, nor was his permissions changed). Both my Admin Asst and I used
his user login and password on our separate client machines to enter the
db and gain access to the form he uses. Both of us were able to edit the
form (logged in as him) with no problems, yet he is still unable to edit
the form from his computer. That, to me, would suggest that the problem
lies with his machine. The only problem with that assessment is that it
doesn't make sense that "something" could be different on his computer to
not allow him "Write" capabilities on an MS Access application.
Networked computers don't work that way (singling out
certain computers to misbehave).
Neither did / do "unnetworked computers", but there are lots of causes for
individual computers in the network to misbehave.

Today's desktop computers may be easier for the user to access, but under
the covers, they are far more complex even than mighty mainframes of just a
few years ago. There are an incredible number of apparetnly-minor items
that can have major effects. The problem likely does "lie with his
machine", but it may be software, hardware, settings, permissions, or a
number of other things. Even if all the machines are presumably loaded with
identical software by a centralized department, there are many individual
settings that can have unanticipated effects.
Running WinXP w/ MS Office Pro 2003.
Nothing unusual there...

Q. 1: Are you up to date with all Service Packs for both the Operating
System (SP 3 is the latest, but there are still a few problems surfacing, so
SP 2 is just fine) and for Office Pro 2003 (SP 3)? In both cases, on the
menu Help | About will show the current service pack.

Q. 2: When you say he is "authorized", that sounds as if the database is
secured with Access Workgroup Security (sometimes called User Level
Security, or ULS). Is that the case?

Q. 3: What is the physical location of the database being executed, aka
"front end"? (That database would contain queries, forms, reports, macros,
and modules. It should be on the user's machine, not on a server.)

Q. 4: What is the physical location of the database containing the tables
and data, aka "back end"? (It should be on a shared folder, and linked by
all users from the front end DB on their own machine.)

(NOTE: If the database is not split into "front" and "back" ends, it should
be. From your description, it does sound as if it is split..)

Q. 5: Every user should have full permissions on the folders where both the
front and back end databases reside. (NOTE: The login to Access itself is
immaterial to this; it is the Windows and network logins of the using
computer to which these permissions apply. That's why you and your AA can
have different experiences from your own machines using his ID and
password.)

Q. 6: You say this user can't "edit the form". Do you mean "use the form to
work with data", or do you mean "modify the design of the form"?

Actually, if the database is split, and there's no "local data" on the
user's copy, it might be a good idea just to copy a fresh, new copy of the
DB (usually all the "installation" required, if Office is loaded on the
machine) to the problem machine and try that copy to see if there's any
difference.
Has anyone every experienced a similar malady and, if so, how was the
problem resolved?
I'm sorry there is not a quick, easy, snap-the-fingers answer. With the
answers to these questions, it's likely someone here can either make
specific suggestions, or determine the next questions to ask you. (It may
well not be me, but someone else.)

Larry Linson
Microsoft Office Access MVP

Jun 27 '08 #2

P: n/a
Thanks Larry:

A1: Yes, IT keeps up with all Service Packs and we are current (SP3 on
both)

A2: We utilize Access ULS on this departmental db

A3&4: It is a 'split' db in the classic sense as you described

A5: Only our Department employees have access to the folder where the db
resides and he is a member of our department

A6: Sorry about the loose use of the term 'edit'. In this case, it means
'write' permissions. He does not have Administrative rights to include
"Design" permission.

We did use a backup utility to 'reinstall' the fe and it solved the problem
'for a week' and the then the problem 're-appeared' the next week, which is
where we are now. We will try that again.

Thanks again...
Earl Anderson
"Larry Linson" <bo*****@localhost.notwrote in message
news:UGjYj.6538$%g.3310@trnddc08...
"Earl Anderson" <is*****@optonline.netwrote
>One of the users in our departmental db has Read/Write permissions to a
particular form. He was able to access and edit the form at will until 2
weeks ago. His current problem was that he was not able to edit the data
(no message ever appeared telling him he could not change any data). The
only change to the db since he experienced the problem was that a new
version of the db was made available for installation which everyone has
now installed. (The new version did not affect the form the user
accesses, nor was his permissions changed). Both my Admin Asst and I
used his user login and password on our separate client machines to enter
the db and gain access to the form he uses. Both of us were able to edit
the form (logged in as him) with no problems, yet he is still unable to
edit the form from his computer. That, to me, would suggest that the
problem lies with his machine. The only problem with that assessment is
that it doesn't make sense that "something" could be different on his
computer to not allow him "Write" capabilities on an MS Access
application.
Networked computers don't work that way (singling out
certain computers to misbehave).

Neither did / do "unnetworked computers", but there are lots of causes for
individual computers in the network to misbehave.

Today's desktop computers may be easier for the user to access, but under
the covers, they are far more complex even than mighty mainframes of just
a few years ago. There are an incredible number of apparetnly-minor items
that can have major effects. The problem likely does "lie with his
machine", but it may be software, hardware, settings, permissions, or a
number of other things. Even if all the machines are presumably loaded
with identical software by a centralized department, there are many
individual settings that can have unanticipated effects.
Running WinXP w/ MS Office Pro 2003.

Nothing unusual there...

Q. 1: Are you up to date with all Service Packs for both the Operating
System (SP 3 is the latest, but there are still a few problems surfacing,
so SP 2 is just fine) and for Office Pro 2003 (SP 3)? In both cases, on
the menu Help | About will show the current service pack.

Q. 2: When you say he is "authorized", that sounds as if the database is
secured with Access Workgroup Security (sometimes called User Level
Security, or ULS). Is that the case?

Q. 3: What is the physical location of the database being executed, aka
"front end"? (That database would contain queries, forms, reports,
macros, and modules. It should be on the user's machine, not on a server.)

Q. 4: What is the physical location of the database containing the tables
and data, aka "back end"? (It should be on a shared folder, and linked by
all users from the front end DB on their own machine.)

(NOTE: If the database is not split into "front" and "back" ends, it
should be. From your description, it does sound as if it is split..)

Q. 5: Every user should have full permissions on the folders where both
the front and back end databases reside. (NOTE: The login to Access
itself is immaterial to this; it is the Windows and network logins of the
using computer to which these permissions apply. That's why you and your
AA can have different experiences from your own machines using his ID and
password.)

Q. 6: You say this user can't "edit the form". Do you mean "use the form
to work with data", or do you mean "modify the design of the form"?

Actually, if the database is split, and there's no "local data" on the
user's copy, it might be a good idea just to copy a fresh, new copy of the
DB (usually all the "installation" required, if Office is loaded on the
machine) to the problem machine and try that copy to see if there's any
difference.
Has anyone every experienced a similar malady and, if so, how was the
problem resolved?

I'm sorry there is not a quick, easy, snap-the-fingers answer. With the
answers to these questions, it's likely someone here can either make
specific suggestions, or determine the next questions to ask you. (It may
well not be me, but someone else.)

Larry Linson
Microsoft Office Access MVP

Jun 27 '08 #3

P: n/a
"Earl Anderson" <is*****@optonline.netwrote
We did use a backup utility to 'reinstall' the fe and it solved the
problem
'for a week' and the then the problem 're-appeared' the next week, which
is
where we are now. We will try that again.
That is interesting, but I don't have an answer (or even, I fear, a likely
suggestion).

If your database is properly split, you should be able to install the
front-end just by copying it. If you are running with the runtime, a
reinstall may be needed. And, indeed, if reloading the FE does not do the
trick, reinstalling Access might be worthwhile. If you decide to try
reinstalling Access itself, I'd discuss with your IT department whether they
would do an actual repair/reinstall instead of restoring from a backup.

Larry Linson
Microsoft Office Access MVP
Jun 27 '08 #4

This discussion thread is closed

Replies have been disabled for this discussion.