unbound form returns values to table

[Joseph Atie]

i have an unbound sub_form on an unbound form.

i load a recordset to my subform, do some operations and then move on.

now the recordset only has a lifespan long enough to load inself to the form
and then it should expire. give this fact i expeceted taht i would need to
create another recordset on the far side of the form to collect the data that
was modified and update it to the table, i.e allowing a roll back function if
you were unhappy with the changes.

how is it that if i modify the data loaded to the form and then close the
form, the modifications i made show up in the table referenced by the
recordset.

is this the way it is supposed to work? it is very handy but seems to good
to be true.

i am using the line

set form!recordset = rs (rs is the recordset)

does this copy the full recordset to the form? my expectation is that it
would simply populate the forms recordset with the data from the recordset i
called.

 

[David H]

The commonly accepted best practice is to bind the form to a recordset for
the life of the form - from the moment the form opens to the moment it
closes. There are some situations where the recordset of a form will be
changed while the form is open, but very seldom.

i have an unbound sub_form on an unbound form.

i load a recordset to my subform, do some operations and then move on.

now the recordset only has a lifespan long enough to load inself to the form
and then it should expire. give this fact i expeceted taht i would need to
create another recordset on the far side of the form to collect the data that
was modified and update it to the table, i.e allowing a roll back function if
you were unhappy with the changes.

Typically, this is completely unneccessary. Once a recordset is bound to the
form, its bound to the form. Changes to the underlying records are committed
as the user works with the records and takes any one of several actions. If
you are in a situation where you want the user to review all of the records
before committing the changes to the main table, then you should be using a
temporary table.

how is it that if i modify the data loaded to the form and then close the
form, the modifications i made show up in the table referenced by the
recordset.

The changes are made as the users work with the records. The form is merely
a means to access, view and edit the records. It is the fact that the form is
bound to the recordset that enables it to update the records.

is this the way it is supposed to work? it is very handy but seems to good
to be true.

Yes. Let me guess - your prior experience is with ASP.NET, VB.NET, WinForms?

i am using the line

set form!recordset = rs (rs is the recordset)

does this copy the full recordset to the form? my expectation is that it
would simply populate the forms recordset with the data from the recordset i
called.

It is incorrect to think of this as 'copying' the records to the form. When
you bind a recordset to a dorm as in the statement that you provided, you're
essentially telling the form which records that you wish to work with.

 

[Joseph Atie]

thanks very much David,

very informative

my background for your info is c, c++ & java.

im not big on these microsoft languages.

as i said im mainly suprised that the link to the table extends beyond the
lifecycle of the recordset and gives itself to the form.