Paul wrote:
<snip>
Your other alternative might be to use the ODBC interface .....
potentially slow, unreliable
<snip>
Or as I wrote, " ... for Access's internal data store to poke into the
Access database. ... "
That snipped part changes the meaning rather dramatically.
Most heartening indeed.
I had a gut feeling that ODBC or even MyODBC connections might cause
me premature ageing.
Either approach will involve ODBC. The way you use MySql / PostgreSQL as
a backend for access is through the ODBC driver for the database. With
the other approach, your program uses the Access ODBC driver to interact
with the Access database file.
The main difference is that the MySQL / PostgreSQL ODBC drivers are made
for fast, reliable, shared access either locally or over a network. Most
of the real work is done on a proper database server, and the drivers
just "translate" from the ODBC interface used by many applications to
and from the native protocols the database servers speak with their clients.
By contrast, my understanding is that the ODBC drivers used to interact
with Access databases aren't really made for such robust use. For
example, I don't know what the situation is with network access to
Access databases, or if it's even possible from non-Windows machines. As
far as I know, the ODBC driver essentially contains the program that
reads the database file, potentially having to share access with (eg) a
running copy of Access. Shared databases _can_ work well without a
central server, but usually tend to scale poorly and can have
reliability issues. The issues you'd run into sharing your Access
database would be the same sort of thing as people who use MYOB over a
network between several clients encounter - the more users, the slower
and less reliable it gets.
When you consider that a web based application could easily have several
concurrent users...
--
Craig Ringer
