File Corruption

"Klatuu" wrote in message
...
In your case, you are courting disater. Keith's assertion that corruption
from mutiple users using the same database are few and far between is
incorrect. This is probably the most common cause of corruption.

That's not what I said.


There is never any valid excuse not to split a database.

I wholeheartedly agree, but on the issue of sharing a FE, I have some old
applications running on a network where the users do share the same FE and
they have yet (in 10 years) to suffer a corruption of any kind. I would
never set up an application like that now but back then I was rather
inexperienced with Access - I now would not take the risk and do provide
each user with their own copy (and recommend the same to others). I stand
by my original statement regarding corruption arising from shared FEs.

Regards,
Keith.

Thanks,

I don't think I will have the option to put the front end on the user's PC.
No one in the 3 institutions have access to their PC's hard drives. The "My
Documents" is actually a spot on a network drive called the H drive for that
individual. The C drive is locked down, we can't even get into control
panel to change screen display settings, a call the to help desk is required
for that and one of the help desk people remote controls to do this type of
thing. Heck, I can't even make a shortcut on my desktop, I use a portal
desktop to access applications. No applications other than the approved
applications are installed on any Networked PC. I have put in a project
request to see what my options are. As for HIPPA, no patient records are
on here but I think it's secure enough for that anyway, I have included that
question in my project request in case we need to keep patient names for
outcomes etc....These records are demographics on employees, inservice
tracking, inservice sign in sheets, pager numbers, work load tracking
etc...nothing really sensitive or secret.

If my answer is absolutely not for putting an app to the C drive, would it
help at all to make 10 copies of the front end on the shared drive and call
them Steve's Employee, Lindas Employee, etc and have the user only use their
own or must it be located on the computer's hard drive?

Linda


"Klatuu" wrote in message
...
In your case, you are courting disater. Keith's assertion that corruption
from mutiple users using the same database are few and far between is
incorrect. This is probably the most common cause of corruption.

There is never any valid excuse not to split a database. The first issue
you have is maintaing modifications and fixes. Without splitting the
database, this becomes more difficult.

The second, particularly where you have multiple users in multiple
locations, is performance. If you are running a shared unsplit database
or a
single shared copy of a front end on a network, you are doubling network
traffic.

The only proper installation of a multiuser Access application is to have
a
shared backend that contains data only and only data and nothing but data
(notice the empahsis) in a shared network folder and a copy of the front
end
on each user's computer.

As to distribution. Here is a link to a site for an front end updater.
It
is not the only one availabe. If you do some searching, you will find
others, or if you are proficient in VBA, you can write your own. The
basic
concept of a front end updater is that in the backend database you have a
file that contains the current verison number of the front end. It can be
in
an application information or configuration file you already have or you
can
create one. If you are using the technique to improve performance of
keeping
a hidden form open at all times with a persistent connection to a table in
your back end, you can put it there.

When you have a new version of the front end available for the users, put
it
in a folder identified for this purpose and update the front end table
with
the new version number. Update the version number in the back end.

Then in the front end, you have a table that contains the current version
of
the front end mdb. In the Load event of the form you have identified in
Startup, compare the version numbers in the back end and the front end.
If
the front end version is not the current version, open a special mdb that
does nothing more than close your front end and rename it, then copies the
new front end version from the specified locaton and opens it.

That is the simplistic description of how to do it. The point is, there
is
no valid reason to use a shared mdb under any circumstance.

Here is the link:
http://www.granite.ab.ca/access/autofe.htm

"LMB" wrote:

Ed,
I just want to jump in here in regards to a split database. I don't
think I
have the option to have a Front End because there are too many PCs to
install it on, the users want to access the database on the network from
any
PC on any floor of our hospital and from 4 different facilities. Is what
helps having only 1 person accessing the front end at a time or having
the
database split? I could put the front end in a folder on our N drive
and
put the back end in another folder on that drive. I have an idea this
wouldn't be any better but I thought I would ask.

Thanks,
Linda


"Ed Warren" wrote in message
...
Do you have your database split? A backend with just the data tables
and
a front end with the forms,queries, reports, code etc. using linked
tables
to the backend. After you do that you can give each user their own
'frontend' and share the backend. This should reduce, eliminate the
corruption problems you are seeing.

Ed Warren.

"Dj" wrote in message
...
For the second time in as many days, my file has gone corrupt. The
first
time, I had No Locks. From a backup copy, I rebuilt my DB and changed
all
forms and queries to Edited Record Lock. Today, after the file went
corrupt
a second time, I changed to ALL RECORD Lock.

There are only 2 people working in the file and I don't beleive they
were
both working on it at the same time today. I have 3 questions...
1. Has switching to ALL RECORDS Lock reduced my chances of getting a
corruption again?
2. Is it possible for file corruption to happen from an other manner
than
two users editing at the same time?
3. My format is 2002. Would I decrease my chances of having another
corruption happen if I convert to format 2000?

Thanks!

Perhaps I did overlook your statement regarding a shared fe. Since I have
not used that configuration, I can't see that it is a problem. My statement
was actually meant to address a shared, unsplit mdb on a server. Where I am
now, there would be at least weekly corruption. Since I corrected that issue
(about a year ago), we have had no corruption.

"Keith Wilby" wrote:

"Klatuu" wrote in message
...
In your case, you are courting disater. Keith's assertion that corruption
from mutiple users using the same database are few and far between is
incorrect. This is probably the most common cause of corruption.

That's not what I said.


There is never any valid excuse not to split a database.

I wholeheartedly agree, but on the issue of sharing a FE, I have some old
applications running on a network where the users do share the same FE and
they have yet (in 10 years) to suffer a corruption of any kind. I would
never set up an application like that now but back then I was rather
inexperienced with Access - I now would not take the risk and do provide
each user with their own copy (and recommend the same to others). I stand
by my original statement regarding corruption arising from shared FEs.

Regards,
Keith.

See John Vinson's post to this thread, what you are suggesting is close to
what he recommends.

Ed Warren.
"LMB" wrote in message
...
Thanks,

I don't think I will have the option to put the front end on the user's
PC. No one in the 3 institutions have access to their PC's hard drives.
The "My Documents" is actually a spot on a network drive called the H
drive for that individual. The C drive is locked down, we can't even get
into control panel to change screen display settings, a call the to help
desk is required for that and one of the help desk people remote controls
to do this type of thing. Heck, I can't even make a shortcut on my
desktop, I use a portal desktop to access applications. No applications
other than the approved applications are installed on any Networked PC.
I have put in a project request to see what my options are. As for
HIPPA, no patient records are on here but I think it's secure enough for
that anyway, I have included that question in my project request in case
we need to keep patient names for outcomes etc....These records are
demographics on employees, inservice tracking, inservice sign in sheets,
pager numbers, work load tracking etc...nothing really sensitive or
secret.

If my answer is absolutely not for putting an app to the C drive, would it
help at all to make 10 copies of the front end on the shared drive and
call them Steve's Employee, Lindas Employee, etc and have the user only
use their own or must it be located on the computer's hard drive?

Linda


"Klatuu" wrote in message
...
In your case, you are courting disater. Keith's assertion that
corruption
from mutiple users using the same database are few and far between is
incorrect. This is probably the most common cause of corruption.

There is never any valid excuse not to split a database. The first issue
you have is maintaing modifications and fixes. Without splitting the
database, this becomes more difficult.

The second, particularly where you have multiple users in multiple
locations, is performance. If you are running a shared unsplit database
or a
single shared copy of a front end on a network, you are doubling network
traffic.

The only proper installation of a multiuser Access application is to have
a
shared backend that contains data only and only data and nothing but data
(notice the empahsis) in a shared network folder and a copy of the front
end
on each user's computer.

As to distribution. Here is a link to a site for an front end updater.
It
is not the only one availabe. If you do some searching, you will find
others, or if you are proficient in VBA, you can write your own. The
basic
concept of a front end updater is that in the backend database you have a
file that contains the current verison number of the front end. It can
be in
an application information or configuration file you already have or you
can
create one. If you are using the technique to improve performance of
keeping
a hidden form open at all times with a persistent connection to a table
in
your back end, you can put it there.

When you have a new version of the front end available for the users, put
it
in a folder identified for this purpose and update the front end table
with
the new version number. Update the version number in the back end.

Then in the front end, you have a table that contains the current version
of
the front end mdb. In the Load event of the form you have identified in
Startup, compare the version numbers in the back end and the front end.
If
the front end version is not the current version, open a special mdb that
does nothing more than close your front end and rename it, then copies
the
new front end version from the specified locaton and opens it.

That is the simplistic description of how to do it. The point is, there
is
no valid reason to use a shared mdb under any circumstance.

Here is the link:
http://www.granite.ab.ca/access/autofe.htm

"LMB" wrote:

Ed,
I just want to jump in here in regards to a split database. I don't
think I
have the option to have a Front End because there are too many PCs to
install it on, the users want to access the database on the network from
any
PC on any floor of our hospital and from 4 different facilities. Is
what
helps having only 1 person accessing the front end at a time or having
the
database split? I could put the front end in a folder on our N drive
and
put the back end in another folder on that drive. I have an idea this
wouldn't be any better but I thought I would ask.

Thanks,
Linda


"Ed Warren" wrote in message
...
Do you have your database split? A backend with just the data tables
and
a front end with the forms,queries, reports, code etc. using linked
tables
to the backend. After you do that you can give each user their own
'frontend' and share the backend. This should reduce, eliminate the
corruption problems you are seeing.

Ed Warren.

"Dj" wrote in message
...
For the second time in as many days, my file has gone corrupt. The
first
time, I had No Locks. From a backup copy, I rebuilt my DB and
changed
all
forms and queries to Edited Record Lock. Today, after the file went
corrupt
a second time, I changed to ALL RECORD Lock.

There are only 2 people working in the file and I don't beleive they
were
both working on it at the same time today. I have 3 questions...
1. Has switching to ALL RECORDS Lock reduced my chances of getting a
corruption again?
2. Is it possible for file corruption to happen from an other manner
than
two users editing at the same time?
3. My format is 2002. Would I decrease my chances of having another
corruption happen if I convert to format 2000?

Thanks!

Joan Wild's website contains a concise links page:
http://www.jmwild.com/Accesssecurity.htm
I know that Jack MacDonald's article has some information about setting up
individual shortcuts, as do other links on that page. I expect that a
virtual local hard drive (the H: drive in your case) would be the same as a
physical local hard drive for purposes of distributing front ends (which can
be customized as needed for certain users or groups).
I am just learning about this stuff, so all I can do is point you toward
information I found helpful.

"LMB" wrote in message
...
Thanks,

I don't think I will have the option to put the front end on the user's
PC. No one in the 3 institutions have access to their PC's hard drives.
The "My Documents" is actually a spot on a network drive called the H
drive for that individual. The C drive is locked down, we can't even get
into control panel to change screen display settings, a call the to help
desk is required for that and one of the help desk people remote controls
to do this type of thing. Heck, I can't even make a shortcut on my
desktop, I use a portal desktop to access applications. No applications
other than the approved applications are installed on any Networked PC.
I have put in a project request to see what my options are. As for
HIPPA, no patient records are on here but I think it's secure enough for
that anyway, I have included that question in my project request in case
we need to keep patient names for outcomes etc....These records are
demographics on employees, inservice tracking, inservice sign in sheets,
pager numbers, work load tracking etc...nothing really sensitive or
secret.

If my answer is absolutely not for putting an app to the C drive, would it
help at all to make 10 copies of the front end on the shared drive and
call them Steve's Employee, Lindas Employee, etc and have the user only
use their own or must it be located on the computer's hard drive?

Linda


"Klatuu" wrote in message
...
In your case, you are courting disater. Keith's assertion that
corruption
from mutiple users using the same database are few and far between is
incorrect. This is probably the most common cause of corruption.

There is never any valid excuse not to split a database. The first issue
you have is maintaing modifications and fixes. Without splitting the
database, this becomes more difficult.

The second, particularly where you have multiple users in multiple
locations, is performance. If you are running a shared unsplit database
or a
single shared copy of a front end on a network, you are doubling network
traffic.

The only proper installation of a multiuser Access application is to have
a
shared backend that contains data only and only data and nothing but data
(notice the empahsis) in a shared network folder and a copy of the front
end
on each user's computer.

As to distribution. Here is a link to a site for an front end updater.
It
is not the only one availabe. If you do some searching, you will find
others, or if you are proficient in VBA, you can write your own. The
basic
concept of a front end updater is that in the backend database you have a
file that contains the current verison number of the front end. It can
be in
an application information or configuration file you already have or you
can
create one. If you are using the technique to improve performance of
keeping
a hidden form open at all times with a persistent connection to a table
in
your back end, you can put it there.

When you have a new version of the front end available for the users, put
it
in a folder identified for this purpose and update the front end table
with
the new version number. Update the version number in the back end.

Then in the front end, you have a table that contains the current version
of
the front end mdb. In the Load event of the form you have identified in
Startup, compare the version numbers in the back end and the front end.
If
the front end version is not the current version, open a special mdb that
does nothing more than close your front end and rename it, then copies
the
new front end version from the specified locaton and opens it.

That is the simplistic description of how to do it. The point is, there
is
no valid reason to use a shared mdb under any circumstance.

Here is the link:
http://www.granite.ab.ca/access/autofe.htm

"LMB" wrote:

Ed,
I just want to jump in here in regards to a split database. I don't
think I
have the option to have a Front End because there are too many PCs to
install it on, the users want to access the database on the network from
any
PC on any floor of our hospital and from 4 different facilities. Is
what
helps having only 1 person accessing the front end at a time or having
the
database split? I could put the front end in a folder on our N drive
and
put the back end in another folder on that drive. I have an idea this
wouldn't be any better but I thought I would ask.

Thanks,
Linda


"Ed Warren" wrote in message
...
Do you have your database split? A backend with just the data tables
and
a front end with the forms,queries, reports, code etc. using linked
tables
to the backend. After you do that you can give each user their own
'frontend' and share the backend. This should reduce, eliminate the
corruption problems you are seeing.

Ed Warren.

"Dj" wrote in message
...
For the second time in as many days, my file has gone corrupt. The
first
time, I had No Locks. From a backup copy, I rebuilt my DB and
changed
all
forms and queries to Edited Record Lock. Today, after the file went
corrupt
a second time, I changed to ALL RECORD Lock.

There are only 2 people working in the file and I don't beleive they
were
both working on it at the same time today. I have 3 questions...
1. Has switching to ALL RECORDS Lock reduced my chances of getting a
corruption again?
2. Is it possible for file corruption to happen from an other manner
than
two users editing at the same time?
3. My format is 2002. Would I decrease my chances of having another
corruption happen if I convert to format 2000?

Thanks!

"LMB" wrote in message
...
Thanks,

I don't think I will have the option to put the front end on the user's
PC. No one in the 3 institutions have access to their PC's hard drives.

Even C:\Temp or C:\Windows\Temp?

Keith.

"Klatuu" wrote in message
...
Perhaps I did overlook your statement regarding a shared fe. Since I have
not used that configuration, I can't see that it is a problem. My
statement
was actually meant to address a shared, unsplit mdb on a server.

Well that's a huge no-no in my book :-)

Where I am
now, there would be at least weekly corruption. Since I corrected that
issue
(about a year ago), we have had no corruption.

"Keith Wilby" wrote in message
...
"LMB" wrote in message
...
Thanks,

I don't think I will have the option to put the front end on the user's
PC. No one in the 3 institutions have access to their PC's hard drives.

Even C:\Temp or C:\Windows\Temp?

The C drive is completely hidden from any view. I did split my database and
in a folder on our reginal network called N:CP_Mgr_ET, I have a folder
called ETBackend where I put the backends of 2 of the databases. Then in
the folder called a friendlier name Employee Databases, I have the front
ends. I created a new database and imported all the tables for the BE, I
created a new database and imported all of the objects for the FE. They are
working but take much longer to load and are a tad bit slower than the
complete database. Is that normal?

Linda