Updating from ADO recordSet

  • Ok, I going to expose my ignorance of handling remote recordSets and/or Views in ADO. I'm in the planning stage of a project using Flash Remoting and ADO .Net. The Flash client has no problem consuming an ADO recordSet then after updating, passing it back to the object and reconstructing the recordSet with the changes. Question being, what do I have to do to get the new recordSet to Update (as is) SQL without having to parse through the recordSet?
     
    Example
     
    1. Flash - Request Specific Query
    2. Object -Create ADO.recordSet from SQL
    3. Flash - pickup RecordSet and disconnect
    4. Flash - Update Data
    5. Flash - reconnect to Object and reconstruct recordSet
    6. Object - Update SQL (as is) from recordSet
    7. Done
     
  • Assumming that you really mean the following:

    1. Flash - Request Specific Query
    2. Object -Create ADO.recordSet from SQL and disconnect
    3. Flash - pickup disconnected RecordSet
    4. Flash - Update Data
    5. Flash - reconnect to Object and send marshalled recordSet
    6. Object - Update SQL (as is) from recordSet
    7. Done
     
    Then step 6 only needs to set the recordset's Connection property to an active connection object, then call the UpdateBatch method.
     
    If Flash and Object are in separate processes, then ADO at the Flash program will send only changed data back to the Object (with appropriate keys to do the update) at step 5.  This will include inserts and deletes as well as updates.
     
    If Flash and Object in same process (Object is an inprocess DLL running in same process as Flash (or inetinfo?), then the updates will be extracted during step 6 when the UpdateBatch is called.



    Mark

  • Thanks, it's good to get a sane answer for a change. I have a religious war going on here. The Flash developers say you can do it, but it takes a bunch of complicated code to parse through the data. On the other side, I have the .Net developers saying it's easy but they doubt Flash remoting is going to handle it correctly...then go into a tizzy telling me I should be using web forms. When I tell them both I think we should go with a pure XML solution, they all hit the floor kicking and screaming.....ugh

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply