Access and the web

[wshore]

I'm still unclear about Access db and the web. I'm converting a VB6 app to VB.net. I'm aware that on the desktop, Access really can't handle more than 8-10 concurrent users.
I thought, however, that from a web server each user would be "served" his/her own instance of the app - such that 100 people using the app would each have their own instance of the program and Access concurrency problems would not be an issue.

My question: Is this true? Can Access ever be a decent choice in VB.net on the web?

 

[JohnH]

Multiple web users accessing the same backed database is equivalent of multiple client users accessing same backend database. Concurrency applies the same. The difference is that the ASP.Net worker process would appear as a single user for the database, but different user threads would still have concurrency issues and the multiple of connections.

 

[wshore]

Thanks for your reply. Sorry to seem obtuse, but I'm still not clear. My app is a solitary game. Thus, each user on line would be limited to one connection to the database. And each of, say, 500 users would be limited to one connection each. Does the "one connection per user" solve the concurrency issue?

 

[JohnH]

And each of, say, 500 users would be limited to one connection each. Does the "one connection per user" solve the concurrency issue?

It would only mean you could have up to 500 simultaneous connections to the database, where each connection could inherently affect any part of the data in every which way.

From Concurrency (computer science) - Wikipedia, the free encyclopedia

In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other.

From Introduction to Data Concurrency in ADO.NET

When multiple users attempt to modify data at the same time, controls need to be established in order to prevent one user's modifications from adversely affecting modifications from simultaneous users.

 

[wshore]

OK. Once again, thanks for responding. Things are now in sharper focus. Here's my last attempt to save Access if possible. In my app, no records in the database are ever changed. No deletions. No additions. No records altered. The app simply runs queries and operates on the results. Does this lessen the concurrency problem?

 

[wshore]

I should have added that after each query, the app closes the database and then vb code only operates on the results.

 

[JohnH]

In my app, no records in the database are ever changed. No deletions. No additions. No records altered. The app simply runs queries and operates on the results. Does this lessen the concurrency problem?

With no modification to data there is also no data concurrency. Then the question is only the possible high workload and volume of simultanous connections to Access. According to my research there seems to be a 64 connections per process limit. Knowing that web requests for concurrent users usually don't happen all at once and all the time, and combine that with the knowledge of .Net connection pool which maintains and reuse underlying connections, I think theoretically an Access backend could in that scenario handle a higher volume of users to a web application, but once 65 users need to an open a connection simultaneously it would break.

after each query, the app closes the database and then vb code only operates on the results

That's how ADO.Net operate, and it is also inevitable in ASP.Net environment where all user interaction with the server app is per request-response basis.

 

[wshore]

Thanks

Thanks for hanging in there, John! You've been very helpful and kind.