Request for recommendations: shared database without a server

Diez B. Roggisch deets at
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 
> higher-ups.

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 mailing list