Announcement

Collapse
No announcement yet.

Q: ADODB, Recordset, AddNew (MSSQL)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Q: ADODB, Recordset, AddNew (MSSQL)

    Hi all,

    I should probably have taken this to some ADO/VB forum that I do not know but, well, I only trust you guys

    I access an MSSQLServer 2005 database from VBA (for prototyping, we're gonna hire a real programmer to do it really well).
    I open a recordset and will add records to it.
    I navigate with .movefirst and .movenext methods
    Edit: I open the recordset with LockType = adLockBatchPessimistic and Cursortype = adOpenStatic (and, funnily enough, it still updates the .recordcount() propery when I add a record.... )

    My question:
    If I use the .AddNem method, where will that record be located? Will it depend on the PK of the table, the order sequence of the SQL I opened the recordset with or at the end?

    I realise there is no such thing as an "End" in a RDBMS, but as I can navigate and have .BOF and .EOF properties, it at least acts is if "End" exists.

    I hope I can be certain I will find added records at the "end" when I have .movenext-ed through all the records I originally got.

    Is the question clear at all at least?

    Hope you can help.
    Last edited by Umfriend; 19 April 2006, 00:39.
    Join MURCs Distributed Computing effort for Rosetta@Home and help fight Alzheimers, Cancer, Mad Cow disease and rising oil prices.
    [...]the pervading principle and abiding test of good breeding is the requirement of a substantial and patent waste of time. - Veblen

  • #2
    It's been YEARS since I've had to do ADODB programming. And even back then I just used it as a pass through to invoke stored procedures on the SQL server.

    Unless you're doing something funky, why should it matter where in the table the record gets added?

    I did use recordset objects for listing data sometimes... or if I need to batch process some records I'd build a recordset of the records I'd need, loop through it and call a stored procedure using paramaters values derived from the columns of the recordset.

    Can I ask why you're using ADODB instead of ADO.Net 1.1 or 2.0?
    P.S. You've been Spanked!

    Comment


    • #3
      It matter because I process dumps of records where either:
      -1- The record is already known in my DB, in which case
      -1a- If attributes are the same I am OK (some are allowed to change, I can just update)
      -1b- If not, then I need to keep track of versions (change existing versions and insert new one)
      -2- The record is not known in my DB in which case I need to insert a new record

      So I am looping through two recordsets of which one (say TInput) only gets updated records and the other (say TMyDB) gets updated, inserted etc. I also need to keep track which records in TMyDB are not in TInput even though I would expect them.

      People that have used AS (now ASTRAC) (and they are far and few between) may remember this as a Match/Merge operation. I think Focus had a simial Merge thing.

      No real reason to choose ADODB over ADO.net, it just came to me. Personally, I do need to be able to use whatever from Excel-VBA and, well, recordsets just came across more natural then datasets... Remember, I'm just prototyping here.
      Join MURCs Distributed Computing effort for Rosetta@Home and help fight Alzheimers, Cancer, Mad Cow disease and rising oil prices.
      [...]the pervading principle and abiding test of good breeding is the requirement of a substantial and patent waste of time. - Veblen

      Comment

      Working...
      X