Q: two forms, one table

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm using Access 2003 in a multi-user environment. I am planning on creating
two forms, both bound to one table. The reason for this is the first form is
already filled up and I need to add a new subset of data.

Is this recommended and what are the things I need to watch out for if I do
this? The secondary form will be a child to the primary form (ie. whatever
record the primary form is on will be the record the secondary form is on).

-Mark
 
I'm using Access 2003 in a multi-user environment. I am planning on creating
two forms, both bound to one table. The reason for this is the first form is
already filled up and I need to add a new subset of data.

Is this recommended and what are the things I need to watch out for if I do
this? The secondary form will be a child to the primary form (ie. whatever
record the primary form is on will be the record the secondary form is on).

It is not recommended and will not work well. If you have two forms,
the second form will give an error "this record is already locked by
another user" - the other user is YOU, on the other form.

Two suggestions: one, use a Tab Page. You can put multiple controls on
the first tab, additional controls on the second. And more critically:
if you have more fields in your table than will fit on a screen, your
table structure is very likely WRONG; fifty or sixty fields in a table
is extremely wide! Might your table structure be at the root of the
problem?

John W. Vinson[MVP]
 
John Vinson said:
It is not recommended and will not work well. If you have two forms,
the second form will give an error "this record is already locked by
another user" - the other user is YOU, on the other form.

Two suggestions: one, use a Tab Page. You can put multiple controls on
the first tab, additional controls on the second. And more critically:
if you have more fields in your table than will fit on a screen, your
table structure is very likely WRONG; fifty or sixty fields in a table
is extremely wide! Might your table structure be at the root of the
problem?

John W. Vinson[MVP]

Thanks for the advice. I think I will use tabs, as you suggest. As for your
second suggestion... yes, I didn't design it the right way initially. But it
was built quick since it was (supposedly) a temporary solution and now that
it actually will be obsoleted in a few months, my manager is saying there's
no reason to change the underlying architecture now.
 
Thanks for the advice. I think I will use tabs, as you suggest. As for your
second suggestion... yes, I didn't design it the right way initially. But it
was built quick since it was (supposedly) a temporary solution and now that
it actually will be obsoleted in a few months, my manager is saying there's
no reason to change the underlying architecture now.

Ok... but sometimes it's worth taking time now to save time later. A
properly structured database will be easier to update and maintain.
Your call though of course!

John W. Vinson[MVP]
 
Back
Top