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
|
|||
|
|||
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 |
#2
|
|||
|
|||
Why does my database have two files to it?
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 |
#3
|
|||
|
|||
Why does my database have two files to it?
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 |
#4
|
|||
|
|||
Why does my database have two files to it?
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 |
#5
|
|||
|
|||
Why does my database have two files to it?
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 |
Thread Tools | |
Display Modes | |
|
|