A bit far-fetched
>> "Multiple Concurrent Users - Because Jet (our database engine) is inherently multiuser, you can have up to 255 people editing the site at the same time. They all simply open the same CityDesk file over a LAN or VPN and CityDesk takes care of the rest."
http://citydesknews.com/CityDesk/fog0000000068.html
Isn't this claim a bit far fetched for an Access database? I can see maybe 10 - 15 users and that may even be pushing it.
Granted it may depend on how many users are actually updating at one time. If you have 255 users and only 1 person is updating every minute, that's fine but if you have 255 users clicking save at the same time, I think the database would become corrupt and a lot of users would get the locked message or the connection would time out.
Did you guys actually test like 10 - 20 users hitting save at the same time? I don't have the capability myself, but I do test 2 at time to ensure I'm catching the proper record locking errors etc..
JJ
Wednesday, November 26, 2003
I have a financial application running in Access with 200 users connected. In 5 years it has never crashed or become corrupted.
Matthew Lock
Thursday, November 27, 2003
You're not likely to get more than one user updating the same record in the database.
If you had more than one it would depend on he kind of locking.
Is it the Jet engine or SQLdesktop (the old MSDE) that is being used?
Stephen Jones
Thursday, November 27, 2003
Access get's a bad rap. Why, I don't know.
I've been using it professionally, to develop RealApplications(tm) since v2.0 in 1994. If properly constructed, and carefully coded, Access/Jet can easily handle the theoretical (published by MS) maximum of 255 users. I've got several apps that have been in production for going on 10 years now that prove it.
The problem is when people don't know what they're doing, and the application performs poorly. They then go shooting off at the mouth that "Access is crap", when really they're covering up for the fact that they don't know what they're doing.
I tend to agree that "Access is crap" for a lot of situations (for other reasons) and have migrated away from it for the last 4 or 5 years, but I still do a huge amount of Access development and for most of my projects and for these it does very well.
The proof is in the pudding. Write you some VB/VBScript/VBA/Whatever (the poison of your choice) that opens up 255 connections to Access and start throwing transactions at it. See what it does. I'll bet it does a whole lot better when you actually test it than you were lead to believe by hearing it through the grapevine that "Access is crap". It really does quite well!
Sgt. Sausage
Thursday, November 27, 2003
But it's often the Access developers themselves that give you this idea.
Try and get an answer on the Access forums as to when you will outgrow Access, and they will tell to go to SQL server for an attendance and marks module for a small high school.
Then there is the question of inexplicable bloat. I've had Access databases bloat from 200KB to 20MB in half-a-day. Compact on close solves the problem, but has it's own perils with a large number of users.
Also there is the awful security model, which you need the equivalent of a JD to understand thoroughly.
Stephen Jones
Thursday, November 27, 2003
>> "Write you some VB/VBScript/VBA/Whatever (the poison of your choice) that opens up 255 connections to Access and start throwing transactions at it."
The problem with this statement is that one program cannot simulate - simultaneous access to a database. You need two or more physical machines networked together.
Also, why don't you share some of the ways in which you ensure the database does not become corrupt.
Just because you have an application with 200 users doesn't mean they are pushing the database. Maybe only 1 - 5 are attempting a save at the same time. To really test it, you would need 200 physical machines networked together with 200 physical users. All 200 users would attempt to save a record at the same time.
Thursday, November 27, 2003
>> "The problem is when people don't know what they're doing, and the application performs poorly. They then go shooting off at the mouth that "Access is crap", when really they're covering up for the fact that they don't know what they're doing."
No one in this thread said that access was "crap". You wrote your post to sound way too defensive. As if people are attacking you.
What do you mean by, "people don't know what they're doing." and the implied "I know everything." Give examples of the things that "people" do wrong.
Thursday, November 27, 2003
Doesn't everybody write intelligent insert/update/delete wrappers anyway to give it a fair go? You know concurrency checking routines, lock checks etc, I mean we're professionals, right?
Realist
Saturday, November 29, 2003
Realist:
No. That's the job of the DBMS. Otherwise you'd be writing your own DBMS (maybe that's the point of your message and I didn't notice the </sarcasm>?)
MR
Monday, December 1, 2003
Recent Topics
Fog Creek Home
|