Centuries ago, Nostradamus foresaw when esoteric@3times25.net (Geoffrey) would write:
> Michelle Murrain wrote:
>> On Tue, 2003-11-04 at 12:46, Geoffrey wrote:
>>
>>> I've got a client who is following my suggestion that they replace
>>> a set of excel spreadsheets with a database solution. They are
>>> looking at two proposals, postgresql solution or an Access
>>> solution. The requirements will include vpn connectivity from one
>>> site to another. It appears they will be going with the Access
>>> solution. I've got concerns regarding this based on research I've
>>> done that seems to indicate that Access, when used in a multi-user
>>> solution is easily corrupted. Does anyone have any
>>> knowledge/experience with such issues?
>> Um, use both??
>> We've been having some success using Access front ends with
>> postgresql
>> back ends. Takes away the data corruption/scalability issues, but keeps
>> the strength of the Access reporting and data entry interfaces.
>
> Okay, so how do you approach this? Access front end will talk to
> postgresql? Pointers to any docs would be appreciated.
Use the ODBC driver, just as you would if connecting Access to any
other Real Database System.
<http://gborg.postgresql.org/project/psqlodbc/projdisplay.php>
You don't get perfection for free; MS Access hasn't got a perfect
model for dealing with concurrent access to data, but at least file
corruption should go away, and you'll be able to initiate backups
without having to kick all the users out.
There will still be something of a scalability issue, at least
compared to SQL Server; the latter has a scheme where queries
automagically get turned into cursor declarations. But you should be
a good few steps ahead...
--
(format nil "~S@~S" "aa454" "freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"I think that helps the users too much." -- CSTACY
