Hi Orange,
Yes of course, I'm aware of your byline. Marks to be awarded out of 10?
I had problems with recordset clones. I've always understood that a clone used the same recordset as the original but that the pointers/cursors/bookmarks - call them what you will - are different. Well, the procedure is triggered by an After Update event on a field and I expected both the original recordset and the clone to have the new field value. Not so, the original (bound recordset) has the new (after update) value and the clone has the old (pre update) value. What started to be a fairly elegant solution became more messy by having to cater for this anomaly. I tried updating the clone, successfully, but this generated a message that another user/process had updated the record and I couldn't suppress that message.
I'm using clones to avoid jumping all over the place with the original bookmarks, which would probably cause a run time error anyway. In fact I even go so far as to clone a clone - now there's posh!
I think there's scope for making the code a little more elegant and a little slicker but once the basic problem's solved, I tend to lose interest. One thing I should have done is to grab the table for exclusive update.
Hope this survives the transposition to v2003.
MSAF32Records.mdb