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... diez -- http://mail.python.org/mailman/listinfo/python-list
