Results 1 to 6 of 6

Thread: Update SQL Server/Table with RecordSet [VB6]

  1. #1
    Hyperactive Member
    Join Date
    Apr 03
    Posts
    308

    Question Update SQL Server/Table with RecordSet [VB6]

    Given that I know how to generate a Recordset from an SQL Query (for example, I am able to do a Select * FROM Table and return that information in a recordset).

    Question is can we do something similar for the other way? Meaning can we take a Recordset and insert it into an SQL Table in a similar way?

    See, my problem is I need to import information into the SQL Table, my only options are a) inserting each row by row into the SQL Table or b) generate a Recordset with all my rows and sending the entire thing (in one shot) to the SQL Table.

    Can this be done?
    If so anyone able to provide an example/sample?
    Thanks,

  2. #2
    PowerPoster techgnome's Avatar
    Join Date
    May 02
    Posts
    21,633
    Yes it is possible.... but it comes with a price, and a pretty hefty one at that.


    Get your recordset, when you get it, make sure that you use a CLIENT SIDE cursor that is BatchUpdatable.

    Disconnect your recordset (.ActiveConnection = Nothing)

    AddNew all you need to.

    When done, reconnect (.ActiveConnection = you connection object here) and use the .BatchUpdate method. This is where the price comes. While the adding to the recordset is fast, you are now transmitting the entire data set back to the server (this is going to include any rows that were already in the table) and for any new records, server will now need to do the insert row by row. Meanwhile, if something goes wrong, there's no telling 1) What row caused the problem, and 2) What state is the data in now? What got saved, and what didn't?

    TG
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.-I also subscribe to all threads I participate, so there's no need to pm when there's an update.*
    *Proof positive that searching the forums does work: View Thread *
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *
    * Use Offensive Programming, not Defensive Programming. * On Error Resume Next is error ignoring, not error handling(tm).
    "There is a major problem with your code, and VB wants to tell you what it is.. but you have decided to put your fingers in your ears and shout 'I'm not listening!'" - si_the_geek on using OERN

  3. #3
    Hyperactive Member
    Join Date
    Apr 03
    Posts
    308
    Hummm....

    Few things I need to mention in reponse to your idea.

    a) The recordset is not build from the SQL Server/Table, it is done manually (completly disconnected at all times) and therefore all information in the recordset is NEW


    As for the methods, considering the price...
    Would it be better just to "INSERT" line by line ?
    However this way allows me to trace exactly where issues would occur and stuff.

    Problem with that is my application only "connects" to the SQL Server to do specific actions, so if I did line by line my application would 1- Connect to SQL, 2- INSERT, 3-Disconnect for EACH row.

    What do you think is more effective?

  4. #4
    PowerPoster techgnome's Avatar
    Join Date
    May 02
    Posts
    21,633
    Where are you getting the data from? A file or something? If so, forget a recordset.

    Here's how I do it:
    Create a Stored Procedure to insert the data (done before hand)
    Then in the code:
    1) Create a command object, add all the parameters (don't set values)
    2) Open the file
    3) Establish the connection
    4) Set the command's connection to the new connection
    5) Begin loop (while there's data in the file)
    6) Set each of the parameters to the data imported for the current line
    7) Execute the command
    8) Repeat loop until we reach toe end of the file
    9) Close File
    10) Close connection

    Done.

    TG
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.-I also subscribe to all threads I participate, so there's no need to pm when there's an update.*
    *Proof positive that searching the forums does work: View Thread *
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *
    * Use Offensive Programming, not Defensive Programming. * On Error Resume Next is error ignoring, not error handling(tm).
    "There is a major problem with your code, and VB wants to tell you what it is.. but you have decided to put your fingers in your ears and shout 'I'm not listening!'" - si_the_geek on using OERN

  5. #5
    Hyperactive Member
    Join Date
    Apr 03
    Posts
    308
    Source is an EXCEL File (TEST.XLS).

    Stored Procedures huh.
    I have never played with those, guessing I should do some reading.

    Stored Procedure to insert date.
    I don't seem to see the different between that and an INSERT besides the fact that it looks like the connection will stay open for the entire Stored Procedure which could do all rows opposed to open/insert row/close loop I was thinking of.

    I am assuming examples for this type of situation are not simple enough to write up, i'll look into it.
    Thanks,

  6. #6
    PowerPoster
    Join Date
    Oct 02
    Location
    British Columbia
    Posts
    9,758
    A Command can be based on a SQL string, it does not have to be a stored procedure. There is very little speed difference between a Command executing a SQL statement vs a Stored procedure. The difference comes at the first execution only. Every sql statement needs to be "Compiled". A Stored Procedure is "Compiled" when it is saved but a SQL Statement is compiled at runtime. However, set the Command.Prepared property to True and SQL Server will only need to compile the SQL statement once. The compilation is saved in a cache and is used by every execution afterwards.

    Using a Command would be more efficient than executing the sql statement directly through the Connection.Execute method. It also eliminates some of the hassles you may encounter when dynamically creating sql statements through code.

    I would recommend that you open the connection before the loop begins and close it after the entire job completes.

    VB Code:
    1. Open Connection
    2.  
    3. Set objCmd = New ADODB.Command
    4.  
    5. With objCmd
    6.    Set .ActiveConnection = Some ADO Connection
    7.    .CommandType = adCmdText
    8.    .CommandText = "Insert Into SomeTable Values(?,?,?,?)" 'question mark for each field
    9.    .Prepared = True 'important when executing sql statements in a loop
    10.  
    11.    'the database can populate the parameters collection for you
    12.    'by calling the Parameters.Refresh method.  
    13.    'Note: this results in an extra database hit and more network
    14.    'traffic but shouldn't be a huge deal
    15.    'Also, using Refresh depends on the SQL Statement - make
    16.    'sure you verify that it generates the intended parameters.
    17.    '.Parameters.Refresh  
    18.  
    19.    'otherwise populate the Parameters Collection manually
    20.    .Parameters.Append .CreateParameter(.... 'do for each ?
    21.    .Parameters.Append .CreateParameter(....
    22. End With
    23.  
    24. Do Until EOF
    25.     '...Get File Data
    26.     'Set Parameter Values
    27.      objCmd.Parameters("ParamName").Value = File Data 'do for each parameter
    28.    
    29.      objCmd.Execute , , adExecuteNoRecords
    30. Loop
    31.  
    32. Close Connection

    If there are lots of rows to insert, it would be more efficient to use variables declared as ADODB.Parameters, one for each field, rather than going through the Parameters Collection everytime.

    One more note - If you are inserting records and need to use the new Identity column value elsewhere in your program - then you should(actually you must) use stored procedures.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •