View Single Post
  #2 (permalink)  
Old March 4th, 2005, 12:53 PM
mmcdonal mmcdonal is offline
Friend of Wrox
Points: 9,611, Level: 42
Points: 9,611, Level: 42 Points: 9,611, Level: 42 Points: 9,611, Level: 42
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: Mar 2004
Location: Washington, DC, USA.
Posts: 3,069
Thanks: 0
Thanked 10 Times in 10 Posts

I have a few questions here about the structure of these tables, and how they are used in the forms.

I will assume this:

ConID - PK
EnvNo - FK (should go to TransID, not EnvNo, even if this is what is displayed)
Name - text
Desc - memo

TransID - PK
EnvNo - text or number
Money - Currency

If you create a form using AutoForm (for example) while on the tCon, or primary, table, then you have the tCon table data showing on the main form, and the tTrans table showing up in the subform.

1. Why is there a text box on the Main tCon form to enter tTrans.Money when that field is available on the subform already?

2. If you want to give the user the option to view the data in the subform in normal form view, why not have a button to switch between formview and datasheet view in the subform, rather than have data entry for the subform on the main form?

A more elegant way to do this if you want the data entry form to LOOK like the main form is to create a form on tTrans, and then create a query and subform to show the tCon data (locked) on the top of the tTrans form. You could even have the tTrans form show the complete tTrans data for that tCon account at each record.

For that matter you could also use the autoform wizard to creat the main form and subform - both in form view, then add a second subform showing the tTrans table in datasheet view below the first subform. As transactions are entered in the first normal subform, requery the second datasheet tTrans subform.

In any event, I wouldn't rely on an unbound text box and button to put data into a table when bound forms work more reliably.


Reply With Quote