Is your application multi-user, or will there only ever be one user connecting to the database? I ask because, if there may be multiple users, what you're asking for simply cannot be done reliably using Access. If it is single-user then it can be done, but it's messy. It would be better if you used a server-based database, e.g. SQL Server Express.
To get the last ID generated by the database, you must execute a query. Because SqlClient supports multiple SQL statements per command, it's a doddle for a SQL Server database. Instead of SQL code like this:
INSERT INTO Person (GivenName, FamilyName) VALUES (@GivenName, @FamilyName)
you simply change it to this:
INSERT INTO Person (GivenName, FamilyName) VALUES (@GivenName, @FamilyName); SELECT ID = SCOPE_IDENTITY()
That query tacked on the end gets the last identity generated within the current scope and assigns it to the ID column of the source row. That updates the parent DataRow and the DataRelation in the DataSet cascades that change to the child DataRows. That means that the child DataTable is ready to be saved to the database with the correct parent IDs without any manual intervention.
With Access, you can't do that because the Jet OLE DB provider doesn't support multiple SQL statements per command. As such, you must execute a separate query after each insert. That means that you cannot insert multiple parent records in a batch. You must insert one record, query the database for the last ID and update that parent row in the DataSet before you can insert the next parent record. The DataRelation will still cascade the IDs to the child DataTable, so you can then insert the child records in a batch.
In Access, I believe that you would use @@IDENTITY, which is a global variable containing the last generated ID. You are using a separate query to the one that performed the insert so, even if SCOPE_IDENTITY is supported, it wouldn't do you any good here. The problem for multi-user systems is that, if another user inserts after you do but before you get the ID, you will be getting their ID instead of yours and your child rows will be related to the wrong parent. There's just no way around that that I'm aware of.