ADP Main Form Disabled when Editing Subform

  • Thread starter Thread starter kobi via AccessMonster.com
  • Start date Start date
K

kobi via AccessMonster.com

I have an adp project that includes a main form tied to a query that is
manipulated by a criteria string to filter records when opened. The subform
is tied to the main form, the record source is the table to allow editing.
The problem is this.....when you open the form the buttons on the main form
work fine. As soon as you edit anything in the subform, none of the buttons
will work unless you close the whole form and requery the data. I suppose if
I simply requeried the data to reset the main form's recordset that would do
it, but they could have gotten to this form by means of 3 different forms
that filter and there's really no way to know what they filtered for.
Essentially I suppose, I'm looking for something that says, requery the
existing recordset but for the life of me, can't figure out the right combo
to get this to work. Help?
 
I suppose that you must have some sort of problem in saving the subform when
it's data have been modified. You may also have this kind of problem if you
are using the RecordsetClone (or Recordset.Clone? I don't remember the
difference between these two) method; especially if you are using ADP 2000
or 2002 instead of 2003.

Set the UniqueTable and ResyncCommand on both the main form and the subform
and possibly that you will be fine. Using the SET NOCOUNT ON for all of
your procedures is not a bad idea, too.

Take a look with the SQL-Server Profiler to get a better look at what's
happening and, very important, set the error trapping to "Break on All
Errors" to make that any error doesn't go into the silent mode.

Personnally, I never use filtering so I cannot tell you if their use can or
cannot affect the read-only state of your main form.
 
SL> RecordsetClone (or Recordset.Clone? I don't remember the difference
SL> between these two)

Recordset.Clone - you do
RecordsetClone - Access does

Vadim
 
you should store your parameters instead of passing them around; for
this very reason.

I usually make a table and it's called 'SysAppSettings' with a PK of
SPID; an integer..
then I store parameter values in that table.

then; instead of worrying about 'which form called this form' then you
write it once and you're done

-Aaron
 
VR> Recordset.Clone - you do
VR> RecordsetClone - Access does

Actually, there's yet another interesting difference.

recordsetclone is always writeable, i.e. changes to recordsetclone are
reflected in the recordset.

For example, if you move the cursor of recordsetclone in before_update
event, the form will actually get udpated. A practical exmaple: before
updating field C to new value, you want to find out if there's already
another record with the same value. You might use the following:

recordsetclone.filter="C=" & c.value
cancel = (recordsetclone.recordcount>0) ' or maybe > 1, subj. to testing ;)

However, running it will cause field C to update to the new (dirty) value
anyways. Access 2002 will be still thinking that the field is dirty, but
field's property OldValue will change to the new value once .filter is
executed. Hitting Undo in Access will result in "undoing" the field to the
new value that we just thought we canceled.

Recordset.clone by default creates the same writeable clone; but it allows
optional parameter LockType, making it possible to have read-only clone. The
above problem can be solved by the following:

dim rs as recordset
set rs=recordset.clone(adLockReadOnly)
rs.filter="C=" & c.value
cancel=(rs.recordcount>0)

Since rs is read-only, moving the cursor won't update it, and the original
data will stay dirty.


Vadim Rapp
 
Back
Top