Here's the problem:
Me.GMDB2DataSet.Master.AcceptChanges()
Me.GMDB2DataSet.HigherTaxa.AcceptChanges()
Me.GMDB2DataSet.Genera.AcceptChanges()
Me.GMDB2DataSet.Species.AcceptChanges()
Me.GMDB2DataSet.Localities.AcceptChanges()
Me.GMDB2DataSet.Stratigraphy.AcceptChanges()
Me.GMDB2DataSet.References.AcceptChanges()
Me.GMDB2DataSet.Persons.AcceptChanges()
When you tell the DataSet to AcceptChanges, it does just that - accepts the changes and resets whatever flag it uses to indicated that there are currently no changes to the DataSet. So, when you call Update after calling AcceptChanges, the DataSet indicates that there is nothing to Update, so no Update is performed.
Here's what MSDN says about AcceptChanges:
Both the DataRow and DataTable classes also have AcceptChanges methods. Calling AcceptChanges at the DataTable level causes the AcceptChanges method for each DataRow to be called. Similarly, invoking AcceptChanges on the DataSet causes AcceptChanges to be called on each table within the DataSet. In this manner, you have multiple levels at which the method can be invoked. Calling the AcceptChanges of the DataSet enables you to invoke the method on all subordinate objects (for example, tables and rows) with one call.
When you call AcceptChanges on the DataSet, any DataRow objects still in edit-mode successfully end their edits. The RowState property of each DataRow also changes; Added and Modified rows become Unchanged, and Deleted rows are removed.
If the DataSet contains ForeignKeyConstraint objects, invoking the AcceptChanges method also causes the AcceptRejectRule to be enforced.
So, either remove the AcceptChanges calls, or move them to after the Update calls.
Also, I believe that calling Update automatically calls AcceptChanges, but I'm not sure.
I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson