You've touched on many issues here.

I don't think you should reengineer your code in the way you suggest.
That would be committing the same mistake as those who add an
autonumber primary key to every table i.e. done out of habit, knee
jerk reaction rather than engaging the brain. Fix bugs instead ;-)

Think back to when MS were promoting ADO over DAO ("In previous
versions of Access, Data Access Objects (DAO) was the primary data
access method. That has now changed. Although DAO is still supported,
the new way to access data is with ADO..."
http://msdn2.microsoft.com/en-us/library/aa140015(office.10).aspx).
Even in that climate, MS were not suggesting that DAO code should be
reengineered using ADO.

I don't create SQL schemas for myself. I work on behalf of other
people which means I have domain experts to consult and the internet
for background research. Because writing specs is what these guys do
all day, they tend to be meticulous. Much implementation is deferred
to the coder (or their technical lead) but most of the *data* issues
are resolved during spec reviews. So it rarely the case that I don't
know in advance things like largest positive/negative value to
support, precision and decimal scale, default value, rounding
algorithm, domain checking and validation rules, etc.

Due to the nature of the business I've been involved with (corporate
entity modelling, financial reporting, workflow management, pensions,
hospital prescribing) I have encountered only one attribute a where a
designer explicitly asked for a floating point value (and I still
wonder whether it was the right choice).

So I've always had to work with very precise values and, frankly, I'd
be surprised if I were the only one. It seems to me that genuinely
floating point data seems to be far more frequent in the natural
sciences than in business environments. Hence, I'm biased against
floating point data types because of their approximate nature.

It may well be the case that at the higher end of the date range you
mention that Double was the best data type for your purposes. I've
only been exposed to Jet since version 3.51 which had CURRENCY but I
am most familiar with Jet 4.0 which introduced the DECIMAL type. Both
are fixed point types. The main differences are that CURRENCY exhibits
banker's rounding by nature whereas DECIMAL exhibits rounding by
symmetric truncation (a.k.a. no rounding) by nature, and that
CURRENCY's precision (19) and decimal scale (4) and fixed, though of
course reduced values are possible using validation rules e.g.

CREATE TABLE Test (
data_col CURRENCY DEFAULT 0.00 NOT NULL,
CONSTRAINT data_col__precision_5 CHECK (data_col BETWEEN -999.99 AND
999.99),
CONSTRAINT data_col__decimal_scale_2 CHECK (data_col = FIX(data_col *
100) * 0.01)
);

I think what you should do is review the list of new features (as well
as the bug fixes and existing features whose behaviour have been
altered) so see if you can take advantage of them in future
development. So, as regards Decimal, you really should have done this
literally years ago (pity anyone who decided, I'll defer for this
release of Jet..." <g>) For example, user level security and
replication have been removed from Jet with effect from ACE and even
if you don't plan to port to Access 2007 format I think the direction
the Access team is taking with the engine should inform your current
development plans.

In conclusion: reengineer it? probably not. Re-think it? definitely
yes! :)

Jamie.

--