Bound vs Unbound Text Boxes to enter data

[RetiredGuy]

I need to write an app (split database with 4 input computers) where our club sells from one to twenty items (each a record of only 6 fields) by cash, check, or credit card. I have populated a form with unbound text fields to allow all of the records to remain visible on the screen prior to adding the records to a main database table. A calculated unbound field will keep a running total of the records entered above on the form. A need exists for the input persons (of little experience) to review each record (six fields) before entering it to the main table. A customer receipt may need to be printed with all of the items purchased before the records are added to the main table and I am guessing that an interim table might work best to hold the records (for printing) before entering the records to the main table. Again, unbound fields would be used, I think.

Question: Is something like this better done with bound or unbound fields? If unbound, I would use VBA coding to add the records (and everything else needed) rather than the automatic entry of records by Access......

I have tried to find a sample database with similar requirements or a template to adjust, but I haven't found any yet....appreciate any help..

 

[MarkK]

Bound fields are way easier, but you say a couple of times that records have six fields. What fields are those? And how are your tables structured? I would avoid temporary tables unless the other alternatives are way too slow. I don't see why a receipt should be printed before the data is entered in a table. Printing is way easier if you make a report based on data in a table.

hth

 

[RetiredGuy]

Thank you for your response....with 3 or 4 persons adding records to the main table, and with no pointer to each individual typist (or customer), it would be difficult to grab the records needed to form the receipt and print it for the current customer.....I am considering adding a checkbox after each six fields on the form to allpw each typist (all are inexperienced with computers) to review their six field entries BEFORE adding the record to the main table (and backup main table).This may seem over cautious but there is little validation that can be used on four of those fields.....

The fields to be used per record are "SellerID" (unique 3-digit number plus the first and last initials of seller), a "SellerInventoryNumber" (optional), a method of payment (an option box for "cash", "check", or "credit card"), an invoice number (six digit number used only for credit card payments), a "=Now()" field to get date and time of record entry, and an amount field for the cost of the item being purchased (which includes sales tax).
A running total text field is kept at the bottom of the form to tally the total owed by the customer. This running total is not needed anywhere as report subtotals and totals will be sufficient.

A customer may have purchased numerous items at one of the club's craft show and each seller provides a "ticket" with each item purchased....so it is important to keep all of the "ticket" entries visible on the screen for review...prior to adding them to the main table....customers may change their minds or not have enough money to buy everything...and it is easier to edit the "ticket" info prior to adding them to the main table....even though I am looking hard at several VBA books, I keep wondering if my approach is really the approach I should be using. I am not that familiar with layout-less forms, or tabular forms, or justified forms to know if there might be a better approach there.

I have placed unbound text fields on a form which allows the typist/cashier (and the customer) to view all "tickets" for that customer, up to 20 "ticket" entries...

 

[MarkK]

It sounds like you are taking a laborious approach. Each record should be in a distinct row in a table, and if you bind your controls to fields in that table and allow data entry directly into those textboxes, your system becomes way simpler.
You seen to want to handle all this data and get in perfect shape before you use a table, except that handling data when it's in a table is way easier. Use tables. Bind UI elements to fields. This is how Access is designed to be used. If you have a parent record that has child records in a related table, use a form and a subform. A subform in datasheet view can show you multiple child records and allow data entry of said records with no code.
hth

 

[RetiredGuy]

Thank you for your input....I will give your approach a try but I am still concerned about letting inexperienced typists edit or delete things after the record has been accepted into the main database....the typists are volunteers placed with sometimes long lines of waiting customers.....and a feeling of having to rush to enter the transaction data....I will have to id the typist on each transaction since 3 or 4 persons will be adding data to the main table....there are 2 tables needed here, a Seller List Table and a Sales Transaction Table. A third if I have to ID the typist. Thanks again...I appreciate your comments.