Re: Not in List Event Error

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

With all respect, that is incorrect.

RI simply prevents you from deleting the data from a parent table when there
are related records in child tables. The cascade update is simply a smaller
override that allows for automatic refreshing of the child tables without
having to systematically refreshing each field where the reference is found.
Cascade delete overrides the safeties and allows for the deletions of the
child tables' records first before removing the primary record in the parent
table.

In reality, one to one relationships are rare, but they do exist. Many to
many are almost non-existent, and I think IF you get a many-to-many it is
probably because of bad database design. I think the same about one-to-one
relationships UNLESS there are special circumstances where they are needed.
In all of my years of programming, only one program required tables based on
one-to-one relationships. If the database is normalized correctly, the most
common WILL be the one to many relationships. I know because I've been
using this structure for years, and I teach this at the college level. I'm
one of those who actually programs in fourth normal form and sometimes
fifth, depending on the way that the table structure is needed.

Like I said before, I have been updating records in a one-to-many
relationship for years without incident, which is the nomal way of
programming. This same code works fine with unbound tables and to some
degree with the bound table, but it is simply going to another record, which
it shouldn't. I am now leaning toward a corrupt table, which I've seen
Access do before.

In the future, I would appreciate it if you would please refrain from
writing as an expert if you truly are not aware of correct data structure.
While I appreciate your enthusiam to offer assistance, your advice for the
RI is absolutely incorrect on the basis of a one-to-one relationship, and
had I been a programming novice, your advice would have had me chasing down
trails that were incorrect. If your table structures are one-to-one, then
may I suggest that you revist them and evalutate whether or not they have
been normalized correctly.




"AccessVandal via AccessMonster.com" <u18947@uwe> wrote in message
news:8dbe3fc7fc0ef@xxxxxx
If you want to maintain RI, you must use one to one relationship. You can't
use one to many. To maintain RI, a child record cannot be an orphan. It
needs
a parent record therefore the form automatically assumes you add a new
record
in the vendor table as well as the child table in Cities (the not in list
event).

Because of the combo box event, you have entered a new child record
without a
parent records. When a user inserts a parent record, this record is not in
Vendor table yet, meaning the form did not save the record when you insert
a
child record from the combo box. Or when a user edits or updates the
Vendor
record for City ID and inserts a new child record that does not have a
parent
record.


Edward wrote:
I guess I do not know what you are getting at here. My relationship is
not
many to many or one to one.
It is one to many, and there is only one instance of city id that is being
associated with each vendor. After inserting a new
city, it does refresh correctly.

RI shouldn't be the problem, and cascade updates is just an override to RI
of sorts. It just keeps me from having to refresh each
field if I make a change in the parent table. RI is pretty much
Programming
101, and I have never had problems working with it in the past
From all of the research that I have been reading, there is nothing
mentioned about a form having to be unbound.
The research simply says that the combo box will update on code that I've
provided in the example. I have never had this problem before
with the inserting of combo box information before. The one I'm using
from
both bound and unbound forms has the underlying recordset pulling
from tbl_cities.

--
Please Rate the posting if helps you

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-formscoding/200811/1



.

Relevant Pages

  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)
  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)
  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)
  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)
  • Unix Programming FAQ (v1.37)
    ... Why use _exit rather than exit in the child branch of a fork? ... Why doesn't my process get SIGHUP when its parent dies? ... How do I create a named pipe? ... How do I compare strings using regular expressions? ...
    (comp.unix.programmer)