This is not the other reason, but the reason of your memory, if you use for testing, I think this is okay, because ACCESS is just a desktop relational database system, not like SQL and other service system. And the driver you are using is ACCESS driven, just like you use ACCESS, it first calls all the ACCESS content into memory or virtual memory, if you have a larger database it will be very slow. And change a driver or a good idea, OLEDB is specialized in the design of the web page of a driver, it is the call of the underlying API, so, the speed should be good. As for ACCESS itself is very slow, I do not think it constitutes the reason why the site is slow. Because ASP itself is also a translation program while parsing and execution, unlike asp.net compiler, so in terms of speed match, ASP with ACCESS is still a viable option. The use of asp.net for development with ACCESS is for testing, and later generally will be replaced with SQL, but with the general are still OLEDB driver, and do not use its own driver.

OLEDB driver is to change your connstr:

connstr = "provide=Microsoft.Jet.OLEDB.4.0;Data Source="&server.mappath("data/avonjxc.mdb")

When I use ACCESS for development, it is for testing. p>

At the same time, I'm just saying it will be better, but it won't make much of a difference if your ACCESS is too large for the situation or your memory is too small. Also, generally close the connection explicitly when the database is finished being used, don't wait for the garbage collector and other programs to recycle it, it will slow things down.

The solution to the ACCESS database is too large, will not be important or associated with the establishment of a table in another database, that is to say, the original database is split, so as to ensure that the database itself is not too large, the use of a connection to a connection although the data does not have much change, but due to the driver does not open a large database and the use of the memory is not too large, to improve speed. Each connection is closed after use, and generally does not cause a similar phenomenon.

As for the PHP+MYSQL results not being delayed, I think that's a bit of a good point.

ASP.net+MSSQL doesn't work? Oh, SQL is a server component, or simply a SQL server, which itself provides such a service, and can be separated from ASP/asp.net/jsp/php etc. on two machines. Furthermore, IL's are inherently much faster than ASP, and SQL is just a data server. So to say only, I think is a bit too absolute in itself.

But the current PHP domestic use more really, such as Baidu is, but in foreign countries JSP is still more, and the use of what kind of language is just a regional, lies in the programmer itself.

If only look at said, I learn JSP, JSP with TOMCAT experiment said JSP is the fastest, and just say PHP and ASP.net is just the same order of magnitude, and learn asp.net, ASP.net experiments also said, ASP.net is the fastest. It's going to be superior to PHP & JSP, so it's not surprising that it's said on PHP that it's the fastest, and which vendor doesn't want to sell more of their stuff? Instant results is also just a too far-fetched statement, it did not meet the big data exchange and database transaction events, if you do meet, no matter what kind of language is time-consuming, and no longer what instant. Not ASP and CGI and PHP/JSP/ASP.net is indeed not in the same order of magnitude, but there are still a lot of programmers in the country who have not transitioned from asp to asp.net yet!

If the database is too large, even if it is a login, that will be slow!

If the database is too large, even if a login, it will be slow!