A different form scheme for addind data

[remsaw]

Hello -

I have a database to track various pieces of equipment and their status. Information I am tracking includes manufacture, part number, specific serial number, location.

I got a lot of help in here getting my tables normalized, and am testing with some small samples of data now - it seems to work real well.

I had an idea regarding inputting data. Rather than make several forms for inputting data into the various tables, (tblManufacturer, tblPartNumber, tblSystem and the like) I thought I would make one form, with several check boxes and combo boxes on it.

The form would have no set record source, nor would the combo boxes have a definitive row source. I would write some simple VBA procedures to set the properties as needed to add to the various tables, and call those procedures with the check boxes.

For example, if I wanted to add data to the tblManufacturer, my VBA would be something like

[blue]Private Sub[/blue] AddManufacurer()
[tab]Me.RecordSource = tblManufacturer
[tab]With cboLarry
[tab][tab]RowSourceType = "Table/Query"
[tab][tab]RowSource = "tblManufacturer.Manufacturer!Manufacurer"

My question is this - Is this an efficient way of doing this, or am I better off making several forms or sub forms? (I tend to think this would be better, giving me an easier way to ensure the look of all my forms are exactly alike.)

Are there problems in the future with this scheme that I am not able to see?

Any advise or comments is greatly appreciatted.

Thanks

Scott

 

[gol4]

I tend use as few forms as possible doing some thing like above what you are doing. The one thing to keep in mind, be sure to use lots of comments so if sonone else needs to work in this datbase later it is clear what you are doing.

 

[JoeAtWork]

I tend to only do this if the different forms tend to share a lot of common functionality. Usually it would be when the records are for basically the same thing, with some slight differences due to different categories or status levels.

I wouldn't do this for widely different types of records (Manufacturer, Part Numbers, System). That makes code maintenance a nightmare. You will need to place multiple controls on the form, setting some to invisible depending on which type of record you will be editing, often they will overlap, etc. (the alternative would be dynamically building the controls and positioning them on form load).

And your code you will be very hard to follow because you will have all sorts of checks of what type of record you are currently editing. It will be very confusing because the majority of your code will have nothing to do with what you are currently working on.

To give you an example of when I would do this type of design, lets say I have two types of Manufacturers, foreign and domestic. There are probably a few ways I have to handle foreign manufacturers differently than domestic. But overall I want the form to behave consistently for all my manufacturers. So first I would put in all controls and code that is common to both types. Then I would put in the code and controls that is used for only one of the types. I would call some sort of Configuration subroutine on form load to hide the controls according to what type of manufacturer I am working with.

But for data that comes from different tables, I would stick to different forms for each one. There is no efficiency gain from one mammoth form (in fact loading it would bound to be slower).

 

[TheAceMan1]

How are ya remsaw . . .

[blue]A form with linked subforms, is the easiest most direct method of entering data in multiple tables with no code![/blue]

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .