This SLX_Common routine is great for removing the rows from a grid recordset.......when I say False it doesn't  delete from the database.....awesome.

 When I reconnect the recordset to the SLX connection......and UpdateBatch.....all changes (Adds, Edits, Deletes) are committed to the database......and we're all still happy....especially since we only do the UpdateBatch when the user clicks on the OK button for the form.....i.e. they can add, edit, delete grid rows to their hearts content....and finally decide to throw all of the changes away and click on Cancel or 'X' out of the database. Yippee!

 So the issue is......

 why is the ADO delete deleting the PARENT Record?!!!! Ouch!

 So if I have A1.gridtablerowID, A2.OpportunityID, A2. Description.....and tell ADO to delete the A1 row left joined to Opportunity.....it's deleting the A2.Table row......

 I note that the SLX RemoveSelectionFromGrid routine builds up a 'stack' of ID's to delete....and then does an ExecuteSQL on those ID's.......

 Is that what I should be doing instead of an UpdateBatch?  I already walk through the recordset and process each ADD seperately as an A1 row insert (learned the hard way that ADO tried to insert the A2, A3 records as well.....guess that tells me about the deletes on the recordset?!?!?). Can I filter on the ADO recordset for the edits only and UpdateBatch on those records only?

Still shocked on how the Parents got deleted.....but thanks in advance for your insight.....