In terms of capacity and performance in manipulating large amounts of data. Which is better, ms access manipulated by vb.net or mysql manipulated by php.
Without any hard evidence data to back this up, I'm sure it is hands down mysql with php where the mysql part would be the killer feature.
MySQL is a full blown relation database management system suited to a variety of application domains. It can performs and scale to support applications with a global audience. It has support for stored procedures and SQL, therefore a lot of the data manipulation can be done in the database system.
MS Access is suited for small office applications with limited number of users with small to medium complexity. It has a Rapid Application Development (RAD) approach to building solutions that is well suited to small "record data and display results" type applications.
I do not believe MS Access is not appropriate for large-scale data manipulation and storage; This is the reason that SQL Server exists.
Also, there are odbc connectors to use asp + mysql. So you could go that route if you are comfortable with ASP. However, as a personal preference, I'd go for php/python + mysql
MS Access is not designed to handle large amounts of data and at the same time perform well (the same can probably be said about VB.NET). It is mainly a tool for desktop databases, not large data centers.
MySQL on the other hand is very scalable (some would argue not, but compared to Access...), and is optimized for great performance with large data. Again, this is relative to Access. MySQL has more competitors in its field than Access has in its own field.
I would say true competitors of Access' database features include OpenOffice Base and SQLite (though without a dedicated GUI).
Competitors of MySQL include Oracle, PostgreSQL, MS SQL Server, and tons more.
Microsoft Access is so unsuitable for concurrent access and large amounts of data that you notice it as soon as you start testing.
Access to SQL Server Upsizing (SQL as a backend)
To scale Access applications to enterprise or web solutions, a recommended technique is to migrate to Microsoft SQL Server or equivalent server database. A client-server design significantly reduces maintenance and increases security, availability, stability, and transaction logging.
Reference: WIKIPEDIA
it shows Access is not able handle large data.
If its a multi-user system doing anything other than pure data-entry at a single workstation (i.e. NEVER fetching data back while data is being entered) then MS Access appears no worse for purpose than MySQL. However in my experience, copying a MDB file from one PC to an apparently identical PC then often a lot of the VBA code / forms and sometimes even the data itself is not available.
MSAccess does not handle concurrency well.
IIRC, the JET engine does implement "Rushmore" (i.e. what other vendors refer to as Skip-scan) which can sometimes use indexes more effectively. AFAIK MySQL does not. This may be a consideration if you have a very complex data schema and the database is essentially read-only.
The one thing you can always be sure of with Microsoft is that very soon they'll release a new development language which will make everything they did before now redundant. Although PHP has seen some changes over the years forward and backward compatability is in a different league from MS VB.
HTH
C. (recovering MSAccess developer)
Although others here have incorrectly claimed that Access can't handle large amounts of data, it can, you will want to go to a more heavy duty system like MySQL or SQL Server when the need for high availability, high concurrency and advanced RDBMS features justify the extra licensing and hardware costs.
All the answers to this question are WRONG because the question itself is WRONG.
Access is not an RDBMS, but an application development tool that allows you to use just about any database engine you like as your data store. Thus, Access can handle any amount of data that the database engine you're using can handle.
Now, Access ships with a default database engine, Jet/ACE, that is not a server database engine. It's file-based and has all the limitations that other file-based database engines have. If you understand that and engineer your application to account for it, you can get quite a lot of mileage out of Jet/ACE in terms of amount of data (subject to the 2GB file-size limitation) and number of users.
The question is basically meaningless as it doesn't define "large amounts of data." OF COURSE Jet/ACE cannot handle enterprise-level data sets -- nobody would (or could) run Amazon off of a Jet/ACE data store.
But within the range of amounts of data that Jet/ACE can handle, Jet/ACE will likely perform very well in many scenarios in comparison to any other database engine, particularly if you're just analyzing and manipulating a data set as an individual user. Access + Jet/ACE can be a very useful toolset for working data sets that fit well within the 2GB limit. Sure, there are some kinds of operations taht Jet/ACE will be a dog for, but likewise for MySQL. All db engines have weaknesses where certain operations are not well optimized.
Choose your db engine according to the tasks and requirements of your project.
The other great thing about using Access + Jet/ACE is that if your dataset outgrows Jet/ACE, you can move it to SQL Server or MySQL or PostgreSQL or Oracle or whatever and continue to use the Access database where you've built all your data manipulation tools. Sure, some of them might have to be slightly re-engineered, but you don't have to start from scratch.