Is there a way?

[deepak]

Hi!
Sppose I make two tables tblName and tblAge. tblName has two fields name
and address. And tblAge has two fields age and telephone no. I want to know
if there is a way where I can desing a form where there are four text boxes
for name, address, age and telephone no, and a button (cmdStore) wiht caption
"STORE" and When I clik on the button STORE after feeding values on those
four textboxes, the value will get stored in tables tblName and tblAge.
Please let me know.
Thanking you all

 

[Keith Wilby]

Please don't multi-post!

 

[Michel Walsh]

Sure, but I suspect your two tables should have a common field, like tblAge
having ALSO the field Name. If such is the case, then, make a query with the
two tables, join them with their common field, name, and make a form based
on that QUERY. You can add the button with the help of the Command Button
Wizard.


Vanderghast, Access MVP

 

[Tom Lake]

Hi!
Sppose I make two tables tblName and tblAge. tblName has two fields name
and address. And tblAge has two fields age and telephone no.

I wouldn't store Age in a table. You'd have to update it every year!
You should probably store a date and calculate Age as you need it.

Tom Lake

 

[Bob Barrows [MVP]]

I wouldn't store Age in a table. You'd have to update it every year!
You should probably store a date and calculate Age as you need it.

.... unless
a) you need to know the Age at the time the record was created, or
b) you need to filter/sort data by age. Having the age stored vs having
to calculate it can potentially make a large difference to performance

 

[Michel Walsh]

Sorting on age would be the same as sorting on date of birth. Filtering is
another matter, but you can filter on a computed expression NOT involving
the field:

Instead of

WHERE DateAdd("yyyy", 18, dateOfBirth) <= Now( )

can be

WHERE dateOfBirth <= DateAdd("yyyy", -18, Now( ) )

which and make the computation just once, and will be able to use index, if
any, on dateOfBirth.


Vanderghast, Access MVP

 

[Bob Barrows [MVP]]

True, for birth date. For historical age, however, storing the record's
creation date would require calculating the age on the fly, which might
impair performance.
What I'm arguing for of course, is the idea that storing the result of a
calculation whose result will never change is not necessarily a bad
thing. Especially if the calculation is time-consuming.

 

[Dale Fye]

Bob,

I would agree that there are instances when storing a computed value
actually does make sense.

Another good example would be an inventory database. I could always
calculate the expected number of items on hand on a given date, but to do so,
across an enterprise would be time consuming. So, occassionally, we store
the expected inventory, along with the actual inventory in a table. That
way, I don't have to compute all of the purchases and sales up to that date
when I want to analyze the difference between expected and actual inventories
(over time).

--
Dale

email address is invalid
Please reply to newsgroup only.