form using many tables

[Robert Painter]

Hi, Not sure if i am having a senior moment but seem unable to solve the
following:

I have a db with tables: tblEmployee
tblSkills
tblEmployeeSkills
tblE-mail
tblCV
I have recently made both email and cv tables to keep normalisation.

I have form frmEmployees which i use to input personal details of Employee
and am now required to input email address and CV. Doing one thing at a time
I have tried to incorporate on my form frmEmployees a text box but cannot
link to tble-mail I just get ?Name# in the textbox. Next I made a subform
frmE-mailsubform and whilst that inputs to tblE-mail, when i return to
frmEmployees the email address has dissapeared although it is still in
tblE-mail. ??

From this form I then go to frmmain to input skills and finally have
frmfindEmployee where all details are put together and this is where i will
be placing a button to link to email.

Where am i going wrong ? I would really appreciate some help on this

Thanx in advance

Robert

 

[DStegon via AccessMonster.com]

This kind of thing is done soooo much easier by unbound forms. Put the
textboxes onthe form that you need to fill in. Have a command button or a
menu that allows them to add. Have the form code add the respective records
to the respective tablea dn insert the PKs as needed (ie E_Mail_ID from the
tblE-Mail into the tblEmployee). SO much easier when trying to update
multiple tables at one time. This allows for data verification before adding
records as well.

 

[Douglas J. Steele]

I cannot think of a single case where an unbound form could be described as
"easier"!

Usually, a combination of a bound form with several bound subforms on it is
simple. And data verification can be done in the BeforeUpdate event of any
(or all) of the forms.

 

[DStegon via AccessMonster.com]

First off you arent helping the person with his issue. Trying to prove
yourself as something does neither him or you any good. Besides, your joking.
Right? Nothing but the simplest of databases would use "connected" forms.
One of our projects has over 350 forms, 510 tables and over 225 reports and I
couldnt name a single form that has bound fields to a connected table or
query.

Do you still use a non-relational table structures as well because it is
"easier" to store the customer name in the sales invoice table than it is to
write a query where the Customer has an ID and the ID is stored in the Sales
Invoice table and joined (Inner, Left or Right) in a query to a Customer
table that stores the actual name? "Easy" is a relative term.

If "connected" was the way to go then why has MS built all the ADO.NET and .
Net language products around the "disconnected" mentality. This really is
not the place to "trash" someone or their opinion of "best practice."
Personally I think anyone that thinks "their" way of doing almost anything is
not someone that should be giving any advice. IMO.

I cannot think of a single case where an unbound form could be described as
"easier"!

Usually, a combination of a bound form with several bound subforms on it is
simple. And data verification can be done in the BeforeUpdate event of any
(or all) of the forms.

This kind of thing is done soooo much easier by unbound forms. Put the
textboxes onthe form that you need to fill in. Have a command button or a

[quoted text clipped - 36 lines]

 

[Robert Painter]

Many thanx to both of you.
I am sure you are both correct in your own way.

Please consider this thread ended.

First off you arent helping the person with his issue. Trying to prove
yourself as something does neither him or you any good. Besides, your
joking.
Right? Nothing but the simplest of databases would use "connected" forms.
One of our projects has over 350 forms, 510 tables and over 225 reports
and I
couldnt name a single form that has bound fields to a connected table or
query.

Do you still use a non-relational table structures as well because it is
"easier" to store the customer name in the sales invoice table than it is
to
write a query where the Customer has an ID and the ID is stored in the
Sales
Invoice table and joined (Inner, Left or Right) in a query to a Customer
table that stores the actual name? "Easy" is a relative term.

If "connected" was the way to go then why has MS built all the ADO.NET and
.
Net language products around the "disconnected" mentality. This really is
not the place to "trash" someone or their opinion of "best practice."
Personally I think anyone that thinks "their" way of doing almost anything
is
not someone that should be giving any advice. IMO.

I cannot think of a single case where an unbound form could be described
as
"easier"!

Usually, a combination of a bound form with several bound subforms on it
is
simple. And data verification can be done in the BeforeUpdate event of any
(or all) of the forms.

This kind of thing is done soooo much easier by unbound forms. Put the
textboxes onthe form that you need to fill in. Have a command button or
a

[quoted text clipped - 36 lines]

Robert

 

[Larry Linson]

No, he isn't joking. And, he is giving best-of-the-best advice for Access:
use "bound" forms, regardless whether using DAO or ADO. ADO is best used
with server databases, and in the "Access Project" (ADP) format -- with
forms bound. Using unbound forms in Access means that you are
reimplementing (and retesting, and re-correcting) hundreds (perhaps
thousands) of person-years of work by the Access product group that supports
bound forms -- and that will be expensive to you, to your employer, or to
your clients.

The size of the project is immaterial -- what is material is "learning the
Access way" so you work _with_ rather than _against_ Access. When you do
understand how Access works, performance is not a problem with bound forms,
nor is "ease".

(Just for comparison, not "bragging", I worked on an Access 2.0 application
with data stored in ODBC-linked tables in an Informix database, that is,
client-server, on a WAN that had a few more objects than you described, with
hundreds of users. The only unbound forms were a few for entering selection
criteria for reports and a few done by a "refugee from classic VB" who
didn't understand bound forms until we taught him, and he enthusiastically
began to use bound forms.) Oh, by the way, did you see in the blogs that
Microsoft is again investing in ODBC and extending it?

The DotNet products are "code intensive" and do not have support for binding
similar to Access. I am sure you are aware that the "ADO.NET" is built on a
different object model from the "classic ADO" in Access, and, I would hope
that you are aware, also, that the DotNet Initiative addresses a different
target application audience (enterprise, usually web-based, applications)
than Access (individual, workgroup, and clients to server databases in a LAN
or WAN, not the web), so comparing the two is like comparing (not just
apples but) watermelons to oranges.

Larry Linson
Microsoft Office Access MVP

First off you arent helping the person with his issue. Trying to prove
yourself as something does neither him or you any good. Besides, your
joking.
Right? Nothing but the simplest of databases would use "connected" forms.
One of our projects has over 350 forms, 510 tables and over 225 reports
and I
couldnt name a single form that has bound fields to a connected table or
query.

Do you still use a non-relational table structures as well because it is
"easier" to store the customer name in the sales invoice table than it is
to
write a query where the Customer has an ID and the ID is stored in the
Sales
Invoice table and joined (Inner, Left or Right) in a query to a Customer
table that stores the actual name? "Easy" is a relative term.

If "connected" was the way to go then why has MS built all the ADO.NET and
.
Net language products around the "disconnected" mentality. This really is
not the place to "trash" someone or their opinion of "best practice."
Personally I think anyone that thinks "their" way of doing almost anything
is
not someone that should be giving any advice. IMO.

I cannot think of a single case where an unbound form could be described
as
"easier"!

Usually, a combination of a bound form with several bound subforms on it
is
simple. And data verification can be done in the BeforeUpdate event of any
(or all) of the forms.

This kind of thing is done soooo much easier by unbound forms. Put the
textboxes onthe form that you need to fill in. Have a command button or
a

[quoted text clipped - 36 lines]

Robert