Access Verses C++ or VB

[jsanders]

This is probably a very old discussion, but I bet a lot of folks would be interested in learning more.

Why does anyone write a database using VB (visual Basic), C++, or any other programming language other than just using Access. It seams to me that there are so many built in functions and so few limitations to Access that it would be redundant to create them from scratch.

I bet I’m really showing my ignorance on this one, so I’ll probably get zinged pretty badly.

 

[boblarson]

Well, here are some reasons:

1. To use Access, you would either need all of your users to have Access or (see #2)...

2. If they don't have Access, YOU would need to purchase the developer version (XP and prior) / developer extensions (2003) to be able to put together a package that used the Access runtime for them to run the database.

3. In VB / C++, you can use and distribute an Access mdb file, with a front end that you have written, for free (provided you follow the licensing requirements as set forth by Microsoft). The restrictions include that the program cannot essentially create a program that competes with Access.

4. Using Access as the development tool, you can run into the situation, where if using ActiveX controls, the references problems that occur with your users on one computer it may work fine, but on another it may not. With a program written in VB/C++, etc., this problem is less likely to occur.

Now, there are good reasons to use Access vs. another programming tool.

If your users will be using the same version, you can do more rapid development, since Access handles a lot of the behind the scenes stuff that you would need to manually code into a VB/C++ program.

Using Access for the development tool can simplify form and reports generation due to the above statement.

I'm sure that several other pros and cons will be shared here. The biggest thing is to determine what is best for a particular situation and not get caught up in "generalities." The best tool for something is dependent on several factors and you must not try to determine the best tool for one job and just assume that will be the best tool for all jobs.

 

[Pat Hartman]

I think the reason is that most IT shops don't really understand what Access is. They always equate it with Jet (the underlying access method) and Microsoft contributes to this by writing position papers comparing "Access" to SQL Server. So the fact that Access can work well as the font end to distributed applications that use non-jet back end databases never occurs to them. The think of Access as a toy due to the limitations of Jet.

 

[The_Doc_Man]

Pat's right. (As usual.) And the ULTIMATE irony is that as a marketing tool, Access is nearly PERFECT as a way to get someone "hooked" into an all-Microsoft solution. Start with Access. Grow with Access. Outgrow Access by expanding to SQL Server. The transition out of Access is never trivial but to SQL Server, it isn't that difficult. There are Wizards to help with most of it.

So as a long-time proponent of "Rapid Application Development" tools, I like Access as a pathway into larger, more robust applications in a controllable, cleanly stageable way.