Access - data vs. forms etc..

  • Thread starter Thread starter John Smith
  • Start date Start date
J

John Smith

My cursory looks at Access, courtesy of some work my wife is doing with it,
has me scratching my head about somethings.

A .mdb file seems to encompass both the database and all the 'code' (forms,
modules, and logic) used to CRUD the data in the tables.

1) Is there any way to separate the database from the code into separate
files, eg. the db is mydata.mdb and the 'code is in a separate file, eg.
code.mdb?

2) Say you have v1.0 of an app and the tables and attributes are populated
with data. You then go and build v2.0 of the app, adding tables and columns
to what already existed in v1.0, and perhaps moving some of the v1.0
attributes into different tables. What is the recommended way to
unload/reload data in this sort of circumstance so as to correctly get the
v1.0 data into your v2.0 database structures?


TIA
 
John,

It's considered a "best practice" to create two (or occasionally more)
databases for applications. One database (front-end) contains Queries,
Forms, Reports, Modules and Macros. The other (back-end) database contains
all data Tables. The front-end is linked to the back-end initially by
means of the menu: File|Get External Data|Link.

With this type of setup, it is relatively easy to deploy design changes to
forms, reports, etc., to the users of databases without overwriting the data
that they have created by giving them a new copy of the front-end database
which they copy over the one they already have. When it is necessary to
make design changes to tables - which must, of course, be done very
carefully - how the change is made often depends on the nature of the
change. If a table requires just that a field or two be added, I can do
that at a client's site, after asking that all users exit the database. If
changes to tables are more extensive, I often use a completely new back-end
and import data from the old back-end to the new. Then, the old back-end is
saved under another name.
 
John Smith said:
My cursory looks at Access, courtesy of some work my wife is doing with it,
has me scratching my head about somethings.
Click to expand...
What small databases are you familiar with? (as against things like Oracle)

-Small systems like say Paradox put each table and each index, each into a
separate file.
-MS-Access tends to lump everything into one file, which you can separate into
code and data much like a client-server model (though Access is not itself
client-server). You have a LOT of control how to separate it, put the tables
into Paradox or dBase tables if you want to do it that way. Put the code into
a VB exe if you want (though that's not a simple conversion)

Why exactly are you scratching your head? Most developers complain of the
bugginess of it, but never it's awesome theoretical flexibility.

Perhaps you should let your "wife" speak for herself? Or "itself".

Chris
 
Back
Top