Yes, update, client party and I ran a test on concurrent users (total = 3 concurrent users) early this morning (clicking on each function/button simultaneously), Access 2000 with current extremely low server memory capabity and query-extensive function, failed to execute some query for 1 or 2 users most of the time for each button/function. Though appreciate your input, but the general belief that Access does not or can't do a decent job on supporting concurrent users well is confirmed as far as I'm and my client for this project is concerned. In actual application use, yes, maybe, it's extremely rare that 3 concurrent users would hit the same button at the exact second, the theory below is unnecessary. But client's customers training session with 30 concurrent users hitting a same button would make you or anyone else cry (for or against Access) and that's part of client's contract with his customer.
So, on the db end for this project, I don't seek any further input, thank you.
>Chunshen (Don) Li wrote:
>
>> Client wants to run 30 concurrent users testing/training.
>
>Lets suppose those 30 users each click a new page every 10
>seconds. That means 3 requests per second. Lets suppose a page
>takes 200 ms to process: you can still run everything over a
>single connection without having any concurrency issues.
>
>You really need to do more work in establishing the true level of
>concurrency before you can asses whether Access can handle the job.
>
>Jochem
[
Todays Threads]
[
This Message]
[
Subscription]
[
Fast Unsubscribe]
[
User Settings]
![]()
