help newbie !

  • Thread starter Thread starter steve
  • Start date Start date
S

steve

Hi,
I am currently trying to update an Access database made back in 97 but with
Access 2.0.
I have very little knowledge of access and of course i had the usual
problems trying to convert it to Access 2002, which is the one I'm supposed
to be working with.

I thought the best idea is to start from scratch with new design and fresh
code. Maybe create an interface in VB.

I have two major questions/problems which I'll try to put in general terms
so as not to give you all the gory details of the databse itself:

The databse consists of approximately >>10 .mdb files.<< : 3 major ones
with forms, lots of tables, queries and macros. Ahe rest of the .mdb files
( 7 ) contain only a couple of tables each, and reside in another
directory. However these (7) mdb files are, as far as i see, the ones
containing the bulky data.
Between the tables in either the same .mdb files or different ones there is
NOT even one relationship! However after looking at the queries i noticed
that a lot of the tables "get related" during the query.

Now keep in mind that these are meteorological data so they tend to be quite
voluminous.

My questions are (and I know i don't give you much information regarding the
database)

1) Remember I'm new to this stuff so is this a normal thing or is everybody
surprised as much as me. If there are no relations why is there a database
and not just create a VB interface to filter out stuff from excel of flat
text files. ??? Unless during the conxersion the relations dissapeared ?

2) Is this idea of multiple .mdb files called splitting?? There is no
server, so the stuff that i read on the web about separating front and back
end doesn't apply to me. Did the creator "split" the "database" into
multiple .mdb files so as not to have problems with Access limitations ? Can
you do that easily? I mean is it very ease with access to relate two tables
residing in different .mdb files? What's the database????? ALL of them
together or there are MANY databases, just related ?

Thank you in advance.
Steve
 
-----Original Message-----
Hi,
I am currently trying to update an Access database made back in 97 but with
Access 2.0.
I have very little knowledge of access and of course i had the usual
problems trying to convert it to Access 2002, which is the one I'm supposed
to be working with.

I thought the best idea is to start from scratch with new design and fresh
code. Maybe create an interface in VB.

I have two major questions/problems which I'll try to put in general terms
so as not to give you all the gory details of the databse itself:

The databse consists of approximately >>10 .mdb files.<< : 3 major ones
with forms, lots of tables, queries and macros. Ahe rest of the .mdb files
( 7 ) contain only a couple of tables each, and reside in another
directory. However these (7) mdb files are, as far as i see, the ones
containing the bulky data.
Between the tables in either the same .mdb files or different ones there is
NOT even one relationship! However after looking at the queries i noticed
that a lot of the tables "get related" during the query.

Now keep in mind that these are meteorological data so they tend to be quite
voluminous.

My questions are (and I know i don't give you much information regarding the
database)

1) Remember I'm new to this stuff so is this a normal thing or is everybody
surprised as much as me. If there are no relations why is there a database
and not just create a VB interface to filter out stuff from excel of flat
text files. ??? Unless during the conxersion the relations dissapeared ?
Click to expand...
It looks like the person who did this did "dynamic
rfelationships" or defining the the relationships in
queries only. Probably not a good idea.
2) Is this idea of multiple .mdb files called splitting?? There is no
server, so the stuff that i read on the web about separating front and back
end doesn't apply to me. Did the creator "split" the "database" into
multiple .mdb files so as not to have problems with Access limitations ? Can
you do that easily? I mean is it very ease with access to relate two tables
residing in different .mdb files? What's the database????? ALL of them
together or there are MANY databases, just related ?
Click to expand...

You have MANY databases, possibly built at different times
for different needs. I don't think it's rare for one
Access application (.mdb) to use data from another Access
application (.mdb). I built one in which assigning
equipment to a patient in an Inventory database upsdated a
Help Desk application with the patient's name and
equipment number.

Your idea of starting from scratch might not be a bad
idea, either in Access or VB. You probably will
understand and document something you've built better than
something you've converted and fixed.

Roxie Aho
roxiea at usinternet.com
 
As I recall, most of the issues around converting from (16-bit) Access 2.0
to any 32-bit version centered around the code; I think the graphics came
over fairly well. (It's been a long time!)

Also being self-taught, I just use terms like "application" and "database",
rather than having a real clear idea of where the boundaries are. But if
you use either and make it clear there are multiple MDB files involved, I'd
imagine most folks would understand what you have.
"Front end" seems to generally be used for the part having forms, queries,
reports, etc.
"Back end" is where the data resides.
Whether you're using a server is really quite irrelevant to whether it's a
split database.
It's less common to have multiple front ends -
are they perhaps used for different purposes?
e.g. one for data entry, another for reporting?
(that would separate this functionality)
Multiple back-ends probably have a history.
One possibility, as you mention, is that the back end is too big to fit
into one MDB (currently limited to 2 GB; in earlier versions it was 1 GB.)
Another possibility is that this data came from an outside source, or
sources, which provided it this way.
It's also quite possible that it was provided without relationships,
and that it was "dirty" enough that some clean-up was necessary before
relationships could be enforced. When data is provided "in bulk" like that,
the usefulness of relationships decreases, I would think.
Someone correct me if I'm wrong - I don't think you can define
relationships across multiple MDB files. I'm even more sure that you can't
enforce relational integrity, which is in my mind one of the main reasons to
define relationships.

As for building your own new solution vs updating the old one -
there's a lot of value in what the previous poster says.
But I'm also a great proponent of "if it ain't broke..."
Especially if it's currently in use, get it going in 2002, then let the
users tell you what the issues are.
If you do decide to rebuild, plan to spend what seems like a lot of time
with the users finding out what their needs are, and how they currently use
the program. This could easily be the biggest part of the project.

This newsgroup is a great place to get information on specific issues -
hope we'll see more of you here!

- Turtle
 
Greatly appreciate your input folks !

You'll probably see me more often here.

Thanx again
 
Back
Top