On a conceptual level, every time you build/create a form, you are building
a template.
So, just copy the database......
A form actually does NOT have any data, and that form is the "template" for
the data in the table. So, by default, a form is a template. Each new record
you add should be using a that same form. So, it would be bizarre, weird, or
not even make sense to try and save a database as a template.
So, in effect, our forms are templates.
You can certainly while looking at a form in design mode, go save-as to make
a copy of a existing form. Furhter, an application with forms etc. is like
to have code, tables, and even reports needed. So, then you simply just copy
the database if you need it for another use.
Use caution here however, as the most amateur mistake you can make is to
copy the database over and over. The instant you make a copy of the database
for each month, or year of data is the instant you are thinking like a
spread sheet. This instant is also the same instant you would be fired from
a developer team!
By making a copy of the database for each set of data, then you cannot
*relate* the data, or even report across time periods. In place of copying
the database for each month (for example) , you simply add ONE column to the
table of data. That way, you can report on data over a few months, or even a
few years.
So, the template analogy you seek does not make any kind of sense in
ms-access sat all. If the data is able to use the same template, why would
you spread it out through many different files all over the place and make
reporting of all that data impossible?
So, I suppose a "save as" template feature is also missing as to take away a
rope that users would hang themselves with. You don't want to encourage uses
to "copy" the same database over and over. You want to *encourage* that user
to simply *DESIGN* an application that solves the task at hand, and
encourage keeping the data in the sample application.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)