Hi BLW,
If you want a 'case number' that you use internally for refering to records
and you want it to be based at least in part on certain aspects of the case
(year, case type), then I suggest you use a calculated field in a query. You
can add the three components you want to produce the results for that
calculated field but you don't have to store it in a table (you just store
the components that go into it individually, like they SHOULD be stored).
As for the third component....the part based on counting the existing
records of that type and adding one, that won't work. If you delete a record
that isn't the last added record of that case type, your count (+1) will give
you a number that's already used. In any event, the number of the last
entered case is NOT going to be an accurate count of the records, so no sense
in trying to make it one. You can always just do a programmatic count of the
records if/when you need it.
If you do it your way (or a 'modified' your way that works), you are either
going to end up storing duplicate data (the individual components of that
make up the caseID plus the caseID itself) OR you are going to have to go
through unnecessary steps to pull out the individual components from the
combined field if, for example, you wanted to do something like filter cases
based on case type.
Either way, it's a bad deal, imo.
For those reasons, I'd just use the autonumber field to give you a unique
primary key for your table, and then use that table in a query and add a
calculated field IF you want to display the combination of fields as a kind
of 'case number' to use to refer to cases within your office, or even to use
to search for cases in your database.
Just my opinion.
CW