yes...VB would be the client, the client would technically be the ADO or DAO or RDO or OLEDB object hierarchy you'd use to connect to the database.

the Server is Access's own database access....the reason for the 100ms is probably because of page caching (buffering of records for increased speed gains (useful only if you actually need that many records). Not sure about access 2000 but access 97 defaults this to 100 cached records. takes time to cache those records. there's a setting somewhere to change that, i;m thinking of you bring it down to 1 or 10 you'd probably get faster performances.

As for the SQL Update querie...from VB's code side it's quicker to do

cSQLString = "UPDATE <TableName> SET FieldName = FieldValue"
AdoCommand.Execute cSQLString

than to do

RecordsetObject.Edit
RecordsetObject.Fields(1) = FieldValue1
RecordsetObject.Fields(2) = FieldValue2
RecordsetObject.Fields(3) = FieldValue3
RecordsetObject.Fields(4) = FieldValue4
RecordsetObject.Fields(5) = FieldValue5
RecordsetObject.Update

Like I said, if your access database is local to your application, executing the SQLString through the command object will be as fast as making access perform the same task....however, if your database is on a server somewhere, chances are using adUseClient will be faster as far as VB's side is concerned.

Hope that helped :-)

and to answer your quote.

If you gain wisdom through your mistakes, I must be ripe to move myself on top of a mountain somewhere by now...LOL