"Robin Hammond" wrote
in message ...

Alan,

the specs seem to have changed a bit from your first question...


Apologies - I probably oversimplified and combined with my lack of
understanding in the first instance I probably missed out important
information.


First, there's no reason that a standard sub cannot handle data
changes without having to have anything in the workbook. You could
put this in a class if you want, which might make it more reusable,
but I don't really see the need.


I guess upon reflection I was just thinking that it would allow me to
go for a 'custom method' such as:

MyProject.Start NOW()

where MyProject is a member of the new class, and Start is a method of
that class.

Another option would be perhaps to use subs:

Start(MyRecord, Now())

Where Start is a sub that takes the record (MyRecord) and Date as
arguments.

The former seems more 'object oriented'? Am I trying to make things
more complicated than necessary?


Adding fields can be problematical if you are doing it remotely.
Hopefully, you mean that somebody has added a field at the db, which
then appears in your worksheet data potentially screws things up
severely in your code.


Definately!

Any fields to be added would be done in the database (an MDB) and
users would only add data to the field in individual records (if they
weren't populated automatically when the field was added).


So, by using recordset objects, and not using a worksheet, you
should be able to refer to the new field purely by name, e.g.
rsData("MyNewField"), which is a lot safer than having to worry
about hard coded cell locations. A few lines are usually all it
takes to handle the new field.

The corollary is that if you must use a worksheet, I'd name every
column so that you can use named ranges to refer to the data rather
than the offsets you are now using.


Good idea, but I am definately bent on removing the worksheet from the
scene now!


To argue the flip side, reasons that you might want to use a
worksheet would be:
you want to edit the data directly in the sheet;
you need the excel maths engine to perform calculations on or
analysis of the data;
you want to be able to view the data in one go in easy tabular form
(although it is easy enough to dump it onto a sheet to do this
without having any other functionality involved)


None of those apply, except the last, and as you point out
CopyFromRecordset is fine for export / reporting purposes if necesary.


Not sure if I've helped much, but good luck with it.

Robin Hammond
www.enhanceddatasystems.com


Immeasurably. I really appreciate your responses.

Thanks again,

Alan.