M
Mike
Hi,
I have an MS Access 2000 application that I almost
finished with. It is built on approximately 50 data
tables and 30 picklist tables. The application GUI
consists of approximately 50 forms which are all
accessible from one main form. This is accomplished with
several tab controls and an abundance of nested subforms.
Everything is just fine except for a very strange
problem. One of my forms is a search engine which
populates a results form, which in turn can propogate to
a "show details" section. This propogation is done my a
line of code within the click event of a command button
on the results page which are similar to:
form_details.form.recordset = form_results.form.recordset
at the moment, i can not remember the exact syntax of the
call, and i can not remember if i am propogating the
recordset or a rowsource in the form of an SQL statement,
but i believe it to be the former...
The problem I have seems to be related to this. The
propogation of the recordset seems to turn off data
access errors somehow... 1 indication of this problem is
that the OnError event of any control on the target form
never fires... a 2nd problem is that the NotInList event
of a combo box never fires... a 3rd problem is that no
error messages ever show up when referential integrity is
violated (combo box not in list errors as well as input
mask violations all do not show up) ...
Instead of firing off errors to the user, the user is
simply unable to leave the control/record on which an
error has occured until the user either provides good
data or the user ESC out effectively removing all changes.
Why do these errors not show up? Is it related to be
propogating the recordset somehow? The recordset is
still updateable, and I can still add new records. But,
its the one difference that I may know of that causes the
error handling on the form to break. Before I propgate
the recordset to the form, new records to that form are
enabled, and error handling on the form works as it
should.
Any help would be appreciated, as I am stumped.
Thanks much,
Mike
I have an MS Access 2000 application that I almost
finished with. It is built on approximately 50 data
tables and 30 picklist tables. The application GUI
consists of approximately 50 forms which are all
accessible from one main form. This is accomplished with
several tab controls and an abundance of nested subforms.
Everything is just fine except for a very strange
problem. One of my forms is a search engine which
populates a results form, which in turn can propogate to
a "show details" section. This propogation is done my a
line of code within the click event of a command button
on the results page which are similar to:
form_details.form.recordset = form_results.form.recordset
at the moment, i can not remember the exact syntax of the
call, and i can not remember if i am propogating the
recordset or a rowsource in the form of an SQL statement,
but i believe it to be the former...
The problem I have seems to be related to this. The
propogation of the recordset seems to turn off data
access errors somehow... 1 indication of this problem is
that the OnError event of any control on the target form
never fires... a 2nd problem is that the NotInList event
of a combo box never fires... a 3rd problem is that no
error messages ever show up when referential integrity is
violated (combo box not in list errors as well as input
mask violations all do not show up) ...
Instead of firing off errors to the user, the user is
simply unable to leave the control/record on which an
error has occured until the user either provides good
data or the user ESC out effectively removing all changes.
Why do these errors not show up? Is it related to be
propogating the recordset somehow? The recordset is
still updateable, and I can still add new records. But,
its the one difference that I may know of that causes the
error handling on the form to break. Before I propgate
the recordset to the form, new records to that form are
enabled, and error handling on the form works as it
should.
Any help would be appreciated, as I am stumped.
Thanks much,
Mike