If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
File Corruption
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! |
#2
|
|||
|
|||
File Corruption
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! |
#3
|
|||
|
|||
File Corruption
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! |
#4
|
|||
|
|||
File Corruption - Follow up question
I think my follow-up question is the same thing Linda is asking, but I want
to re-iterate. If I do split my DB, can the front end be a shared file without problems or does each user HAVE to have their own copy to eliminate/reduce corruption? Thx, Dj "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! |
#5
|
|||
|
|||
File Corruption - Follow up question
"Dj" wrote in message
... I think my follow-up question is the same thing Linda is asking, but I want to re-iterate. If I do split my DB, can the front end be a shared file without problems or does each user HAVE to have their own copy to eliminate/reduce corruption? Thx, Dj It's considered by many to be good practise and it's the configuration I use and would recommend, but AIUI actual documented and repeatable instances of corruption by sharing a FE are few and far between. Keith. www.keithwilby.com |
#6
|
|||
|
|||
File Corruption
The OP, noted only two users, the issue of multi-site, multi-users is a
'horse of a different color'. I have used done both, used one copy of the front-end for more than one user and used multiple copies of the front-end on a server with a common folder, with a different copy for each user. The real key is to get the data tables away from the common user interface. That way when your frontend.mdb becomes corrupt, you can simply replace it, with no data loss. Note: Your user requirements cry for a client-server application. MsAccess is really not the best suited solution for multiple users over multiple sites, sharing sensitive (HIPAA), data. Ed Warren "LMB" wrote in message ... 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! |
#7
|
|||
|
|||
File Corruption
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! |
#8
|
|||
|
|||
File Corruption
I believe Keith's comment was about sharing a front end that is installed in
a shared folder on the network. "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! |
#9
|
|||
|
|||
File Corruption
On Tue, 4 Apr 2006 15:31:02 -0700, Dj
wrote: 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! User contention for editing records is (in my experience) very rarely a cause for corruption. I think you need to look elsewhere! See http://www.granite.ab.ca/access/corruptmdbs.htm for some common causes, cures, and preventions of corruption. Reading downthread, you may want to consider using a terminal server (such as MTS or Citrix) so that your remote users can run Access (on your *SPLIT* database) without having Access running on both ends of "the wire". John W. Vinson[MVP] |
#10
|
|||
|
|||
File Corruption
Thank you all for the feedback and suggestions. I've already split the
database and I'm going proceed with giving everyone their own copy to store in on their desktop even though it will be on the same NT server. Thanks again! "Dj" wrote: 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! |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
If I buy Microsoft office, will I be able to open my old files on | laurelek | General Discussions | 3 | February 13th, 2009 02:56 PM |
How to creat relative and shorthand file path names? | 2dogs | General Discussion | 1 | May 15th, 2005 12:11 PM |
file corruption | alex22 | General Discussion | 3 | August 4th, 2004 11:34 PM |
Continual Error 1321 Trying to Install Office 2003 | Chad Harris | General Discussions | 9 | June 11th, 2004 08:19 AM |
Unsafe Attachments | Ron | Installation & Setup | 2 | June 9th, 2004 01:55 AM |