Amy,
It sounds like your database is not split. There are many reasons to split
a database, and this is one of them.
It is almost impossible to keep your data in sync when you are trying to
make modifications to an unsplit database.
I would highly recommend you shut down production long enough for you to
correct this problem so you will not have the issues going forward.
First, get everyone out of the system.
Make a backup copy of your mdb
Split your database. Tools, Database Utilities, Database Splitter
You will end up with two files. One will have _be added to the file name.
That file is your data. It is commonly referred to as the Back End (be). It
contains all your tables and relationships.
The other file will contain all other database objects (forms, reports,
queries, macros, modules, etc.) it is commonly referred to as the Front End
(fe).
You should put a copy of the be in a server folder where all users have
read/write/delete rights.
You should put a copy of the fe on each user's computer.
This is the correct way to deplay an Access application.
Now, one issue you may run in to would be if not all users have the same
drive mapping defined for their computer. That is one may have the path to
the folder
\\OurServer\AccessApps\Fantastic.mdb mapped as drive G: and another may have
it mapped as M:
The best way to resolve this issue (in fact it is the only way I ever link
to my back ends) is to use what is known as UNC paths. That is using the
actual network path instead of a drive map path. It would be the
\\OurServer\AccessApps\Fantastic.mdb I described earlier.
You can set that up during the Splitting process when it prompts for a
location to put the back end.
Now, when you make changes to your application, you don't have to worry
about whether or not you get the data updated correctly. You don' affect the
data at all. You just deploy a new copy of the fe to each user.
The only time you have to worry about data concurrancy is if you have to
make changes to your database schema. Then, you make your changes in your
test environment and when you are ready to modify the be, you need to get the
users out and update the changes to the back end. The strategy to do this
will depend on what the nature of the changes are.
--
Dave Hargis, Microsoft Access MVP
Amy Schmid said:
KARL DEWEY said:
The part that does not seem to hold the data is the form in the Ag portion
of the database.
Your response does not mean much to me as I can not see what is the "Ag
portion" of the database.
Forms do not 'hold data' - only display and allow data entry. Tables hold
data.
The information is entered on a form and it goes to the table. The only
time we are having this issue is when we are data-entering in the Ag form.
All other data entry points in our database are updating correctly.
I then had to refresh our "live" version with the 'update' version and his data did not hold.
What is a live version vs update version? How is the 'refresh' performed?
We have a working version of the database that we call 'live'
[AcuityVPMDevelopment].mdb. This is the version that all users see and use.
We have a copy of the live version called [AcuityVPMDevelopment_Update.mdb]
Any time we need to add a report, query, table or make changes to anything,
we we use the AcuityVPMDevelopment_Update.mdb version.
When all changes or additions are complete. We change the name of the live
version to [AcuityVPMDevelopment_[date of change].mdb and change
[AcuityVPMDevelopment_Update.mdb] to [AcuityVPMDevelopment].mdb making the
'live' version obsolete, making the 'update' version the new 'live version'.
We then create a copy of the new live version and call that the new 'update'
version.
Confused yet? I was the first three times I had to make changes. . .
To which version is the data entry form connected?
The data entry form is connected to both. It is just a copy of the original.
:
The part that does not seem to hold the data is the form in the Ag portion of
the database.
I have a form with tabs, linked to the table, where the user enters the
information. He made changes. I then had to refresh our "live" version with
the 'update' version and his data did not hold.
We have not had trouble with any other portion of the database where this
same situation (refreshing the 'live' with the 'update' versions).
--
Thanks,
Amy and Jill
Still Newbies, but learning :0)
:
for just one portion of the database and not in others?
What is meant by 'one portion?' Is it one form? Are the textboxes of the
form bound to the fields of the table?
--
KARL DEWEY
Build a little - Test a little
:
Good morning,
We have a "live" database as well as a copy of the database where any
updates and changes are done to ensure that we have a working database
available to users when changes are being made.
This usually works well for us as any data that is entered in the "live"
database appears in the "update" database. However, on several occasions, we
have updted our "live" database and the one portion is not updating properly.
The user is having to re-enter the valid information.
Any ideas on why this is happening for just one portion of the database and
not in others?
I am not sure what other info to give. Please let me know what whould help
you: sql view of something?, list of table information for this portion? . . .
