Why does my database have two files to it?

I recently took over an instrumentation and control group. We have a
database that we keep our calibrations in that has two files to it. I'm not
sure why is that because it's on a network?

I have been looking at it and there is duplicate tables in it, macros that
point to the wrong directories, tables that don't key to the correct piece of
hardware, etc. It's a mess. I am quite familar with excel vba so I am
challenging myself to get familiar with Access related VBA. Will it hurt
anything to copy both files and move then to my home pc to work on? I was
told someone tried this once in the past and it moved data rather than copy
it..... any guidance or links to info would be a huge help.

thanks,
Tim

I cannot say that the following applies to your situation.

It is quite common to have 2 files. One is known as the Front End (FE) and
the other the Back End (BE). The 2 files are created by applying a database
utility to split the database. I cannot say for sure that this is what you
have.

The FE contains the code, forms, reports, Queries etc and the BE contains
the data tables only. The tables are linked to the FE. When viewing the list
of tables in the FE database window, there is an icon at the left of the
table name. If there is a right pointing arrow to the left of the icon then
it is a linked table indicating that you have a split database.

The reason for FE and BE is so developers can make enhancements etc to the
FE and test with a copy of the data without ever touching the real data. When
ready, the updated FE can be copied in and the most that will have to be done
is re-establish the links to the table in the BE.

When a database is split, the default filenames are the original filename
for the FE and the BE has _BE appended to the filename.

If the system is as above and there are no login Id's and Passwords, then
you should be able to copy the databases and take them to another computer.
If there are login Id's and passwords then it is a bit more difficult.
However, after copying to another computer, you will need to open the FE and
reset the links to the correct path to the BE.

Linking in pre Access 2007: This is done via File - Get External Data -
Linked tables. Select the filename where the linked tables are and then
Select all and then OK. (Select all might be questionable so it would be a
good idea to make a note of the linked tables before copying and then only
link those tables on the list.)

Linking in Access 2007: External Data Ribbon - Import section - Access
Icon then similar to above.

--
Regards,

OssieMac


"tbrown7777" wrote:


I recently took over an instrumentation and control group. We have a
database that we keep our calibrations in that has two files to it. I'm not
sure why is that because it's on a network?

I have been looking at it and there is duplicate tables in it, macros that
point to the wrong directories, tables that don't key to the correct piece of
hardware, etc. It's a mess. I am quite familar with excel vba so I am
challenging myself to get familiar with Access related VBA. Will it hurt
anything to copy both files and move then to my home pc to work on? I was
told someone tried this once in the past and it moved data rather than copy
it..... any guidance or links to info would be a huge help.

thanks,
Tim

tbrown7777 wrote:
I recently took over an instrumentation and control group. We have a
database that we keep our calibrations in that has two files to it. I'm not
sure why is that because it's on a network?

I have been looking at it and there is duplicate tables in it, macros that
point to the wrong directories, tables that don't key to the correct piece of
hardware, etc. It's a mess. I am quite familar with excel vba so I am
challenging myself to get familiar with Access related VBA. Will it hurt
anything to copy both files and move then to my home pc to work on? I was
told someone tried this once in the past and it moved data rather than copy
it..... any guidance or links to info would be a huge help.

thanks,
Tim

A cautionary tale. I once joined a development group in a well-known
corporation. I had a smattering of relational theory and some VB, so I
was invited to take over an Access development which was "nearly
finished" as the developer was moving to another project where he had
specific skills. Cost me my job.

Looking back, instead of trying to make that thing work, I should have
got myself up to speed with Access independently (a couple of weeks'
intense study) and then gone back to the original specification and,
while checking occasionally what had been done before, built the thing
again from scratch.

It was never going to work - the table design was just wrong, so
everything that he'd built on top of it had to be wrong. My predecessor
had built everything using wizards, but when you come to an Access
project second-hand you don't see that, and focusing on the surface of
the monster concealed the incoherence at its heart.

Yes, my mistake - I spent far too long simply taking on trust that there
was value there that I had a duty to preserve, but it was a pile. I
could have built it three times over by the time my contract (not
renewed) was up. The original developer had built his
(not-quite-working) edifice in a couple of months, and his productivity
was much praised...

Access is potentially immensely complex, although there are great
facilities in the tool to help you deal with that complexity if you can
learn them. It's also immensely rewarding, as an experienced developer
can produce powerful applications remarkably quickly. However, few
developers document their work in the way that professional software
engineers should - there are so many "idioms" (patterns of doing things)
that after a while it feels unnecessary (I'm guilty too). So you end up
knowing what your precedessor's code does, but seldom why, unless you
have the experience to recognise those common patterns.

So, as a self-declared beginner in Access, at least consider a different
approach. The data should all be there, and Access is so powerful a
development tool that you may be able to recreate it in a way you
understand, starting with the most essential functionality and building
on bells and whistles as you come to understand them. If you need the
thing running quickly, get in someone who already has the skills.

The database will have two files if you have a "front-end" and a
"back-end" - good practice (and a hopeful sign). The back end contains
only tables, and the front-end contains any queries, forms, reports and
VBA modules which make the database an application. Back up both
regularly: the File backup option gives you a useful dated filename.

If you're going to get up to speed yourself in Access, look at the
Access courses on lynda.com - the first few lessons are free, and you
can sign up for as little as a month at very modest cost. There are, of
course, loads of books - I've used the Access Bible.

Good luck!

Phil, London

Here is an article expaling how/why/what is going on.....

http://www.members.shaw.ca/AlbertKal...plit/index.htm

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

thanks for all your comments. I enjoy the challenge.



"Albert D. Kallal" wrote:

Here is an article expaling how/why/what is going on.....

http://www.members.shaw.ca/AlbertKal...plit/index.htm

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada