Bound or Unbound data entry form?

[Guest]

I have a form which would normally be in a master-sub relationship if it were
bounded. This is to enter employee and their associated expenses. However,
my 'customer/mgr' doesn't like the idea of having to do dropdowns to pick
each type of expenses in the otherwise datasheet subform. My new requirement
is to have each expense type be its own textbox. In another word, I will
have 10 textboxes (one for each expense type) on my 'subform' even though the
data entry person might only have 2 entries to input.

My thought was to have the entire form be unbound and do the posting to the
tables via codes when the user click Save button. But this is a lot of work
(meaning having to check for field length, valid data type, etc manually
before posting). Am I wrong in going this approach? Not to mention how to
handle editing an existing record. Is there a happy middle of the road
design? I don't know very much about using unbound form.

 

[Al Camp]

kdw,Absolutely! This is not the way to develop a database application.
Your main form and subforms must be bound to tables for a myriad of critical
reasons, most importantly... referential integrity. There is no half-way
possibilities in that regard.Exactly! Totally unworkable...

As for the ExpenseType, DO NOT create 10 individual fields, one for each
expense! That design will not allow you to properly categorize, total, or
graph those individual expense types. ExpenseType should be one field with
multiple values. With individual fields... what happens when you add
another ExpenseType in the future. All form, queries, and reports will have
to have that field added, and all your code will have to be revised...
throughout the whole application!

If your expense subform is a continuous" subform that may contain several
expense entries, then a combo box is the proper tool. You can have the
combo "open" when the user enters the field, so they just click the
selection they want (like a Listbox) If it's a Single subform then you
could try a ListBox instead of Combo. That would allow the user to just
select a value from a list displaying all ExpenseTypes.

hth
Al Camp

 

[Guest]

kdw,
Al is dead on correct.
Try to explain to your 'customer/mgr/idiont' (oops) that the combo box for
expense type is the correct approach based on the analysis of very
experienced professionals and that to take the approach that he/she/it wants
has the following drawbacks:
1. More time and cost to implement (considerable)
2. More prone to errors (complex code required)
3. Adding new expense types will require additional coding and testing
4. In reality, it is more difficult for a user. (has to look over form to
find correct type)

If you can't convince the user of this, an alternative compromise would be
to use a group of command buttons to select the expense type instead of a
combo box. Then you could still use the master sub format. The only real
downside here would be that you would have to add buttons for additional
expense types.

 

[Guest]

Thank you Al and Klatuu for your feedback. You have highlighted the reasons
for my not too crazy about the the unbound form approach. In the event that
I still must implement it that way, what do you mean about 'group of command
buttons'? I can't visualize how it is supposed to work.

 

[Guest]

Instead of the combo that you wanted to do, create a command button for each
expense type. I would suggest that you write a function or sub that will do
exactly what the combo would do in choosing the expense type and creating the
new record. The from each of the expense type categories, pass the sub or
function a value that will identify which button was clicked so you will know
how to handle it.

 

[Guest]

Thank you for clarifying. I will keep that in mind.