Why use Visual Basic AND Access in same application RRS feed

  • Question

  • I recently had a conversation with a potential client that stated she was looking at an application that the developer claimed was better and easier to use than mine  (access 2007) simply because it combines Access and Visual Basic.

    I played around with standalone Visual Basic back in the early 90's but have used Access for all DB applications for years.  Are there things that Access can't do well that VB is better for?  It seems to me that VBA within Access has all the functionality for screen design and data manipulation that the original Visual basic had.

    Is it possible that the other application is using the integral VBA (Visual Basic for Applications) in Access and just referring to it as Visual Basic to impress the client?? 

    Comments and/or suggestions?

    Friday, July 29, 2016 2:53 AM

All replies

  • Hi Steve Staab,

    The base for VBA, Vb, c# to Automate the Access is Access Object Model.

    The object model is same for every one.

    so it doesn't matter you use VBA, VB or c#. you will get all the features and functionality, properties, methods and events supported by the object model.

    so if you use Vb then also you can able to use all the functionality of an Access that you used in VBA.

    now you will think that then what is difference between all these. because at this stage it looks like same and you think that it doesn't matter whatever you used.

    but there is difference.

    the difference is that VB/c# language itself have much more powerful features and functionality. that is not available in VBA.

    so if you use VBA you are not able to use that functionalities along with Access Object model.

    but if you use Vb/ c# you can able to use object oriented features of these languages.

    This is the very simple description I have mentioned above and does not go in the deep to discuss which object oriented feature supported and what are the advantages of that.

    you can visit the link below to get some more information regarding this topic.

    Advantages And Disadvantages of Visual Basic

    Difference between VB.NET and VBA

    Disclaimer: This response contains a reference to a third party World Wide Web site. Microsoft is providing this information as a convenience to you. Microsoft does not control these sites and has not tested any software or information found on these sites; therefore, Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. There are inherent dangers in the use of any software found on the Internet, and Microsoft cautions you to make sure that you completely understand the risk before retrieving any software from the Internet.



    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, July 29, 2016 4:42 AM
  • I recently had a conversation with a potential client that stated she was looking at an application that the developer claimed was better and easier to use than mine  (access 2007) simply because it combines Access and Visual Basic.

    Hi Steve,

    Interesting to know why that developer claims to make a better application than yours.

    Is that a faster development, a better user interface, a more fancy look of the applcation, more functional possiblities?


    Friday, July 29, 2016 10:31 AM
  • It could very well be that the developer was referring to VBA. Some contractors misrepresent themselves in that way. These developers are just trying to muscle in on your contracts. And how could an application work better and easier if it has the same functionality? The end product is what counts. Not how you got there.

    Yes, VBA has all the functionality of VB. After all, it is just a specialized set of VB that was made for Access.

    I've heard other developers claim such things as using a VB front end is being better than Access alone simply because that was the language they were most familiar with and you don't have to install Access to use their product.

    Bill Mosca

    Friday, July 29, 2016 3:43 PM
  • One big difference is you don't need Access/Access Runtime if more than one user will be using the application.

    We use XCopy deploy to desktops and all use the Access DB on a file share. (All eventually wind up with SQL Server as backend.)

    Next up: WinForms verses WPF

    Or maybe: C# vs VB.Net

    Lots of worms in this can! :)

    Another: Visual Studio is a full blown development environment; Office VBA is, well, VBA.

    Friday, July 29, 2016 3:58 PM
  • Following along Bill Mosca’s line, I would ask your potential client how she is evaluating the potential apps. What are her criteria?

    peter n roth -, Maybe some useful stuff

    Friday, July 29, 2016 4:10 PM
  • Bob, you wrote:

    >Another: Visual Studio is a full blown development environment; Office VBA is, well, VBA.

    We Access developers were excited until MS first announced Office VBA in VS. Then we learned Access VBA was not included. Gotta keep in mind Access uses VBA for Access, not VBA for Office. I think the whole issue is the close ties that VBA-A has so many DAO hooks built in and VBA-O doesn't.

    Bill Mosca

    Friday, July 29, 2016 6:31 PM
  • Access/VBA is as good as it gets for rapid application development (RAD) for single user environment where you need to store data (in a relational system) which will be queried for reporting, analysis since Access is an integrated development environment (backend and frontend are in the same app). 

    Now, depending on what you client needs -- if it is a multi-user environment -- even though Access supports multiple users -- with a sql server backend Access does not do well with error messages, among other issues (if Access is the backend then it's time to take this discussion up with a kindergarten teacher).

    If it is a multi-user environment for testing then I guess Access is still a good bet.  But if it's a multi-user environment for production/enterprise level -- best to go with front end code that can be compiled to .exe with a server back end (Access just has too much subclassing -- heavy weight code -- each function does too much stuff and cannot be streamlined like VB.Net or C# - to function well in multi-user -- Access is a very high level (far removed from OS) development platform) -- just not cost effective.

    Again, if it's single user then Access/VBA truly cannot be beat(en) for ease of development --about as cost effective as it gets for single user.

    Rich P

    Friday, July 29, 2016 9:26 PM
  • Rich

    I have to respectfully disagree with several of your statements. I have several enterprise applications using Access ACCDE front ends with SQL back ends. These can have as many as 100+ concurrent users. It could handle thousands because each user has a local front end. The only limit is front end size. Mine are all under 20 mg each with over 100 forms and reports, thousands of lines of code. The back ends have millions of records which I control through views, pass-throughs, etc. SQL does all the heavy lifting.

    Error messages? That's what error traps are for. Don't blame Access is the developer lacks coding skills.

    Subclassing? Another developer problem.

    Each function does too much stuff? My functions are mostly generic. Years of coding has made me pretty good at re-using code.

    The one drawback Access falls to the ground with is web development. It's still in the dark ages.

    Bill Mosca

    Friday, July 29, 2016 9:44 PM
  • Hi Bill,  Not to dispute the merits of Access, clearly Access has some merits -- it's about proper usage and cost effectiveness.  My personal experience (in multi-user environments) has been that Access is not as cost effective as a compiled platform (VB.Net/C#).  Another factor is this -- Access can yes be maintained by one developer.  But seriously, if the environment has a lot of users (more than 5 or 10) Access would not be the tool of choice (all things considered).  As for the subclassing thing -- Lists are the big deal now -- I create lists of any kind of object I want and use generics, ...  This is very streamlined.  Access is based on several subclasses.  Access is not that generic.  This is where compiled platforms come in -- where you can customize stuff for the required needs.  Access accommodates many needs on a limited basis but you can't really refine it as far as VB.Net/C# can.  But that refinement takes time.  Thus, Access == RAD, but you have a lot of overhead for the functions in Access.  They do a lot of stuff that you will probably only need 2 or 3 things of.  In VB.Net/C# you can make lower level function that only do the things you need without the extra overhead.  It's all a matter of the requirements.  Access is much easier to maintain for smaller environments than VB.Net/C#.  But for large environments (100s or 1000s of users) it is unrealistic to use Access.  These are the distinctions I'm trying to make.  It all depends on what the scenario is.

    Oh, one pet peeve I do have using Access against Sql Server -- error trapping.  I have wrestled with this extensively -- if something goes awry on the server -- all you can get in Access is a meaningless "Error" message even if you have included error traps in your stored procedures.  Access can't read those, it's because of all the subclassing.  Thus, .exe's are better suited.  Just note the distinctions here.  If I didn't know what I was talking about I wouldn't be doing it (20+ years).  I share with all due respect, just note the distinctions and base usage on the requirements.

    Rich P

    Friday, July 29, 2016 11:29 PM
  • I think the post here is Visual Basic Programming (VB) 6.0 or so and not the DOT NET or VS platform is what the post is talking about.


    Saturday, July 30, 2016 3:32 PM
  • Just mixing a little business 101 here -- clients who own their own business or manage an enterprise level business are not foolhardy people.  If you are only going to assemble something that just uses nails you would use a hammer and not a pile driver.  If you need to install I-beams for the frame of a building you will use a pile driver and not a hammer.  Clients know the difference.  If you have an enterprise business you will need a pile driver system -- .Net.  If you have an inter office system, Access may suffice.  As for debating to use VB6 vs VBA -- the only thing VB6 does that goes beyond VBA is you can compile a VB6 app to an exe, but VB6 is no more robust than VBA.  But creating an app with VB6 is stoneage (you can't even use it on the web anymore), get MS Office and create an app with Access/VBA -- VBA is built in to Access.  I would go with VBA if it's not an enterprise level project  (not more than 5-10 users).

    Rich P

    Monday, August 1, 2016 4:34 PM
  • "I would go with VBA if it's not an enterprise level project  (not more than 5-10 users)."

    There is no issue whatsoever with Access with more than 5-10 users!  I have developed and support numerous enterprise Access databases used by 50-80+ users without any problems and have do so for years.  There are numerous people that go far beyond that even.

    I'm by no mean saying developing a standalone VB projects isn't good, but stating ditch access if you have more than 5-10 users is silly.  Access can support it without any problems.  It all comes down to the developer doing a proper job, as is the case with any project.

    Daniel Pineault, 2010-2012 Microsoft MVP
    MS Access Tips and Code Samples:

    Monday, August 1, 2016 4:51 PM
  • As I said, some of my Access applications have 100+ concurrent users. Proper design dictates how well such applications run.

    I've also developed in VB6 but only because that's what I knew at the time.

    Bill Mosca

    Monday, August 1, 2016 5:31 PM