Request for recommendations: shared database without a server
Diez B. Roggisch
deets at nospam.web.de
Thu Oct 5 22:36:20 CEST 2006
Tim Chase schrieb:
>> Access might really be the best solution. It is pretty good
>> for what it is supposed to do, and the quick prototyping and
>> UI-designing are strong arguments for it, especially if there
>> already is a bias towards it.
>> I also _think_ that the whole "db on a shared volume" thing
>> works comparably neat.
> Just a caveat from past experience...I've had trouble with Access (at
> least older version) sharing DBs on a network drive. It didn't work
> /too/ badly, but it scaled horribly. 3 concurrent users was noticably
> slow. 5 concurrent users was painful. Above 10 users was agony.
Yeah, I recall that dimly, too. But at least it worked, only when
putting really much stress on the system it produced inconsistencies
such as doubledly assigned ids and the like. Seems to me that they are
pretty conservative regarding locking.
> Fortunately, I was one of the ones redesigning the replacement system to
> actually use a database server. Granted, as merely a PFY at the time, I
> didn't have much input into the choice of server (MS-SQLServer) nor into
> the language (Visual FoxPro), just got to execute the plans of the
The architectural benefits are for sure, therefore my suggestion to tear
down some walls.
But VFP really can get messy... and at least the late-90ies, early 21stK
ms sql sucked pretty badly, feature-wise access/JET beat the crap out of
it any time back then...
More information about the Python-list