Refreshing DataSet w/ Dbase's Primary Keys

I have a number of records to add to the database so Im using a Dataset to compose the table and then calling the adapter's Update(myDataSet, "myTable") to refresh the data source with the new records.  The problem is with the autonumber primary key the database automatically generates for each new record added to it.  I need this unqiue value for each row of my dataset because I'm creating another table which requires it.

I've been using the adapter's Fill(myDataSet, "myTable") in hopes of refreshing the dataset's primary key field with the proper values from the datasource but with no luck.  However, calling with Fill(myDataSet, "myNewTable"), where myNewTable is just a new table name within the same dataset, does retrieve the actual primary keys from the data source.  The problem I have with the second method is it retrieves ALL the records from the data source, including the newly added items) instead of just the new records, and more importantly the specific coulmn, that arent within the dataset.  

I have no idea what the adapter's Update() command does underneath but using a dataset for all my new records and updating the datasource as one block seems like a more efficient method than calling the INSERT sql command, .ExecuteNonQuery(), then SELECT @@IDENTITY for each record.  But how exactly do i retrieve the actual datasource primary keys for each record within the dataset that was added?  ...Without having to retrieve the entire datasource again?

Hope this makes sense.
Who is Participating?
TheAvengerConnect With a Mentor Commented:
The answer is only one: what you see as "crude" is what is always done and what is the correct way to do it. I suggest the following:

1. Start a transaction (so that either all, or nothing goes into the database)
2. Insert records into A, retrieving their PKs
3. Insert records into B, retrieving their PKs
4. Change the data in the dataset to reflect the new PKs from A and B as FKs in C
5. Insert records into C
6. Commit the transaction

If you were using SQL Server you could try a stored procedure (with relatively the same steps) but using Access does not allow you to do this.

Here is also the code to retrieve the ID with the insert (it's a VB example but I hope you will not have a problem with it):

And once again: belive it or not, this is how it is done in the practise.
Normally the DataSets are "clever" and update/insert only changed/new records. I think they also call select @@identity only for those records, i.e. not for all records. So the data that is not changed is also not sent to the server and not re-retrieved. Based on this I think using the implemented functionality of exactly calling SELECT @@IDENTITY for each record (changed or new) is the most effective one you can have.
anistonAuthor Commented:
I've created an empty database in Access 2000 consisting of 3 tables:

(Table A)
Field 1 = "aID" (Primary key, autoincrement)
Field 2 = "Name" (Text)

(Table B)
Field 1 = "bID" (Primary Key, autoincrement)
Field 2 = "Song" (Text)

(Table C)
Field 1 = "aID" (Foreign key from Table A)
Field 2 = "bID" (Foreign key from Table B)

The relationship amongst the tables is one to many from Table A to Table C, and one to many from Table B to Table C.  I've composed a list of Names to be inserted into Table A and a list of Songs to be added to Table B.  Table C serves as the middle man allowing me to identify what names match with what songs.

Adding new Names to Table A and new Songs to Table B have been easy using a DataSet, DataAdapter, and calling Fill() and Update().  However adding new records to Table C have been difficult.  I'm unable to provide the actual Foreign Key values it requires.  The primary key values in these other tables are determined "after" i add the record to the data source and so if I want to fill Table C i would need to retrieve the entire contents of Table A and B after adding the new records, step thru them for the primary keys and then set Table C.  It all seems very crude.  

Is there a better/correct method for inserting records into my database layout?  Perhaps DataSets arent the answer?
The new generation of project management tools

With’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

After calling DataAdapter::Update you'll need to call the DataSet's AcceptChanges method. This commits everything, and therfore not confuse another Update call.

When I say commit here. I'm not talking about a database commit - the DataSet still marks those tables and rows as per the DataRowState enumeration. AcceptChanges resets this status to unchanged.
Extract from MSDN:

When using Update, the order of execution is as follows:

1. The values in the DataRow are moved to the parameter values.
2. The OnRowUpdating event is raised.
3. The command executes.
4. If the command is set to FirstReturnedRecord, then the first returned result is placed in the DataRow.
5. If there are output parameters, they are placed in the DataRow.
6. The OnRowUpdated event is raised.
7. AcceptChanges is called.

Because of step 7. you don't need to manually call AcceptChanges.
Never noticed that before. I've always called AcceptChanges.
All Courses

From novice to tech pro — start learning today.