"Larry Goldstein" <lgoldste@advanswers.com> wrote:
>Open the database, then for each table, create a recordset, use the addnew
>method to create a buffer for each new record, set field values, then use
>the update method to save the record:
>set db = DBEngine.Workspaces(0).OpenDatabase("C:\TEST\MYDB.MDB")
>'The SELECT here will read all fields in all records. You can restrict

>you get by explictly listing included fields (e.g., rstRecordSet!ID,
>rstRecordset!Customer...), using a WHERE clause to choose which record(s)
>are included, etc. Read up on SQL for more information.
>Set rstRecordset = db.openrecordset("SELECT * FROM
>rstRecordset.fields("Customer") = "My data"
>rstRecordset.fields("Contact") = "My data 2"
>rstRecordset.fields("PhoneNo") = lMyValue
>when done...
>set rstRecordset =nothing
>set db = nothing
>FYI, there are a number of ways to refer to fields. I've excerpted the
>writeup on this below from MSDN.
>Good luck!
>Larry Goldstein
>Referring to Field Objects
>You can identify a Field object by its DAO Name property, which corresponds
>to the column name in the table from which the data in the field was
>retrieved. The Fields collection is the default collection of a Recordset
>object. Therefore, you can refer to the LastName field in the rstEmployees
>Recordset in any of the following ways:
>When using the ! operator, you must include brackets around a field name
>when it contains spaces. For example, the statement:
>strEmp = rstEmployees!Last Name
>will not compile, but the statement:
>strEmp = rstEmployees![Last Name]
>will compile with no problems.
>Within the Fields collection, each Field object can also be identified by
>its index:
>The index enables you to walk through the collection in a loop, replacing
>the index with a variable that is incremented with each pass through the
>loop. Objects in a collection are numbered starting with zero, so the first
>Field object in the Fields collection is number 0, the second is 1, and

>on. The field order is determined by the underlying table. Fields are
>usually numbered in the order retrieved when the Recordset object is opened.
>One drawback to this approach is that you can't be certain which field will
>be referred to, because the underlying table structure may change, fields
>may be added or deleted, and so on.

Thanks for your support -- it worked perfectly. A bit of explanation, I
am not a programmer by profession I simply write VB code to support my consulting
practice. I have not worked with the DAO Object before so I am unfamiliar
with its capabilities.

One additional question -- One of my applications references the Excel object
so that I can open Excel and create spreadsheets and the user must have Excel
installed. However, with the DAO Object reference, will the user have to
have anything installed? When I compile and distribute the application that
references the DAO Object, will the Package and Deployment tool include the
necessary DAO routines necessary for the application to work? I'm a real
neophite when it comes to working with the DAO object so any advice will
be welcomed.

Thanks again.