Why use VB instead of Access for DB programmin?

Hi all! One question; how do you decide whether to just use Access versus using VB to build your DB <g>. If your client already has Access, what is/are the advantages of building the DB with Visual Basic? Thanks for any answer!

More power, control, & flexibility, although VBA is pretty strong, plus you get experience using VB and making VB apps instead of VBA. Also, users could modify your queries, forms, and macros.

There are probably many more reasons as well, but those are the ones off the top of my head....

There sure are many more differences. But the most important is that with Access you can't compile your application (unless you get MS Office Developer's Edition) to be a stand alone program, which also will require Access to be installed on the clients PC as well, where with VB all you have to do is to ship your application (EXE), database and all required DLLs for database access.

------------------

Serge

Software Developer
[email protected]
ICQ#: 51055819



[This message has been edited by Serge (edited 12-29-1999).]

Sorry, but the above is not true: Office developer contains Setup and runtime for Access apps to run them without having Access installed.

True is, that if the user already knows Access and you want to give him the possibility to enhance/change the app later (add reports etc.) Access is the choice. To create a product, VB is the choice, because you have a "real" compiled programm. Initial effort to create a programm maybe slightly greater in VB, Access can be slower in some cases.

Now that I think about it, I thought you could 'sort of' compile a mdb by making it a MDE file.....???

Yes, precompile (P-Code) and hide. But you need Access runtime anyway.

Thanks for the info, all of you! So it seems that IF the client already has Access, & they just want a DB stick with Access. But if they want a Database application from the ground up, I can use VB to develop it. The only downside I see is having to learn SQL to build all the queries for the client; is it difficult to use DAO/ADO to build the backbone/connections of the DB(i.e. all the 'behind the scenes stuff' the user never sees)? Thanks again!

Use, in this order,

1) what the client wants _and_
2) what you're familiar with.

There are some things that are easier to do in Access. There are some things that are easier to do in VB. What's right is what gets the job done, as long as it does one of the 2 above...

[This message has been edited by JHausmann (edited 12-30-1999).]

That's exactly what I meant. You can't compile your application unless you have MS Office Developer's Edition.

------------------

Serge

Software Developer
[email protected]
ICQ#: 51055819

To learn ADO (forget DAO) is not that hard. A tip on learning SQL: Build a query in Access and then look at the SQL statement. It's not always the best style, but you'll learn the basics.

Using access to get a complicated query is nice, but, as Roger mentioned, it puts alot of unnecessary statements in the query that make it more complex than it is.

A good SQL introduction/reference is at http://w3.one.net/~jhoffman/sqltut.htm

No DBMS is ANSI 92 SQL compliant that I am aware of...

Too bad, but right!

It not only puts unnecessary stuf in the statement like always tablenames together with field names, but it's also not ANSI-SQL compliant! In some cases (like joins or the wildcards with the LIKE operator) you will even have to change the Access statement to make it run on SQL Server or Oracle.

Roger