A point in the right direction?

carole

Registered User.
Local time
Yesterday, 18:14
Joined
Aug 24, 2012
Messages
12
I am a supreme newbie at building databases. I can understand and modify existing ones, but I have never built my own. I have one that I need to build, and it will eventually hold quite a bit of data at any given time. It also needs to be able to allow multiple users to input data.

I have a table in which I want to store inspection data per serial number. A set of serial numbers will all belong to one order and all the serial numbers from every order will be in this table. The inspection data will populate the fields, but for any given order not all the fields will apply such that for some records the unused fields will be just blank. When the order is first placed I would select which fields would apply to each order.

From this table I want to have a data entry form that only shows the inspection fields apply to that order. I figure that is easy to do by creating a query to have only those fields and building a form around the query.

My obstacle is this: In 99.9% of the cases each order will have a different set of fields relevant to it, so I want to have the same data entry form have different fields visible depending on what order is being opened. I want the simplest solution possible, but my brain always tends toward complex answers.

I am thinking that writing VBA code to build a new query and form every time we want to enter data for an order would work, and then have the form reset when a different order is opened. But this has my head spinning.

What if I just had a database that held something like 300 forms each of which would be built (from some sort of template) upon receipt of the order? Would this bog down the database over time? Does this completely defeat the purpose of Access?

Any feedback or alternate ideas would be awesome.

Thank you!!!!
 
300 forms? How many fields in this table? And yeah, that sort of defeats the purpose. What you want is a degree of abstraction that allows fewer objects to do more work, not lots of specialized objects that each perform narrow functions. This keeps maintenance tasks low and provides a higher degree of scalability.

When you start a database project I'd venture to say that you'll always want it, in the future, to do more than it was originally conceived for. 'Scalability' happens when your initial design does not lock you in to certain methodologies that are 'hard-coded' into your design -> abstraction.

Does that make any sense?
 
on the order of 100 fields.... maybe I can split it in half if I design my table differently, but I would need to access both tables still for data entry
 
on the order of 100 fields.... maybe I can split it in half if I design my table differently, but I would need to access both tables still for data entry
I could be wrong, but I feel that you need to read up a bit on Normalizing Data. The link I gave you in my previous post should help.
 
Thanks, I am reading it now. any source of information is helpful.

Also, sometimes what I need is a kick in the opposite direction :)
 

Users who are viewing this thread

Back
Top Bottom