December 2, 2001 at 10:10 pm
In a form's grid control, we are using the UpdateBatch method to affect the underlying tables. The problem is that the Recordset populating the grid is created by a bunch of ISNULLs, LEFT JOINs and FULL JOINs leaving UpdateBatch in the dark as which tables to affect. Making matters worse, the Recordset is created by the joining of 3 tables, but I want UpdateBatch to affect a 4th and totally different table. Has anyone come across this situation?
I can think of a couple of workarounds, but the only decent one is still nasty: create a work table that is populated by this "ADO unfriendly" query. When UpdateBatch then executes, a trigger is used to update the proper destination table.
December 3, 2001 at 5:12 am
I think you've stretched the limits of what you can do with ADO. Can't blame it for not knowing what table to update in that situation! In some cases a view that encapsulates the joins combined with an instead of trigger is a nice solution. Might still be with some tweaking, you could branch maybe based on the app_Name() and update your 4th table instead of the underlying source tables.
Another idea would be to walk through the recordset after user is done, look at each record and figure out what needs to be changed and where the change should be done. Not as clean as updatebatch, but more powerful.
Still, neither seems that elegant.
Andy
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply