Visual Basic Versus Access Project

[EriRobert]

Hello,

I'm looking for an objective comparison of the merits of Visual Basic and Access Project (I'm looking at linking with SQL Server backend).

The few comparisons I've come across seem to be from a certain camp (VB/AP) and are rather subjective depending on the writer's preference (or on what they're trying to sell).

I must confess I'm approaching this from the Access side willing to be converted to VB.

I'm not an expert in either VB or Access. Does anyone know of any sites or have any comments on the matter. From my (subjective??) point of view and impressions from others I would start with the following, but am happy to be corrected:

VB is "more" professional (can someone explain this?)
VB is faster
VB doesn't require a runtime - Access does

AP Reporting is superior
AP's continuous forms provide flexible functionality lacking from VB
AP can do anything VB can do

I appreciate any feedback


Robert

 

[zemp]

First off VB does require runtime files. However they are free to distribute, therfore no added cost. Having that said I personally prefer VB.

I find that with Access binds its controls and forms. As a result it's easy to set up but you lose complete control over your app and the data. With VB you can choose to use bound controls if you like or keep complete control over every step. Maybe that's what was meant by "more" professional. This will however require more coding. You are given the choice to bind or not.

Reporting in VB is best done with a third party tool such as crystal reports.

You also mentioned that you are linking with SQL Server. Access is designed for its jet engine. That is where you can really use Access to its fullest and take advantage of all of its features. If you are using SQL server then I feel that VB and ADO may be your best bet. ADO are data conection objects that allow VB to communicate with almost any database.

Thanks and Good Luck!

zemp

 

[EriRobert]

Thanks Zemp for your feedback,

Just a couple of points:

1. I totally agree with you when you say that Access' binding of controls means a loss of control. However this is completely optional in Access as it is in VB. I find that apart from continuous forms I mainly use unbound controls and therefore control all updates to the database tables myself.

2. You've also right in saying that Access is designed to work with Jet. Access Project however is a different kettle of fish, designed to work directly with SQL Server through OLEDB completely bypassing JET. Therefore I communicate with SQL Server via ADO just the way you suggest - remember all the libraries ADO, DAO etc., are available to the Access Programmer as well as the VB Programmer.

3. In my opinion Access' reporting facilities are better even than Crystal.

Anyway thanks,

Robert

 

[zemp]

Sounds like the only reason that you are leaning to Access is because of the reports. The rest (unbound controls, ADO) is entirely interchangeable.

Bottom line, use the tool(s) that you are most comfortable with and that you can get the job done in.

Thanks and Good Luck!

zemp

 

[MichaelRed]

... but a limitation of Ms. A. Reports is the lack of support for graphics in exporting. I do not know if 'AP' has the same issue, and there are some workarounds. However it is -for me- a crippling issue if the db needs to have any large scale (eletronic) reporting. Otherwise, I see little difference between the two.

The Ms. A. reporting capability is -in my opinion- quite good as long as you are able to have all users generate their own reports or you can use snail mail for distribution or are willing to use some of the available tools / techniques to expoert to another format (at least two are available) or if you would be able to use and support the use of Crystal Reports. VB's reporting capabilities are -at best- crippled infants in contrast, however Crystal Reports are quite reasonable - but again require additional support and expense in deployment, It is also not all that hard to programmatically generate printed output from VB - as long as the reports can be 'canned' at least in the sense of data content and layout/format.

Although 'roll-your-own' reporting is not often discussed in these fora, I believe that it is a viable option as long as there is no need for 'ad=hoc' report generation by the end users.




MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[EriRobert]

Zemp,

Its just that I sometimes detect (not in this forum of course) snobbery on the part of the 'Professional' VB Programmer looking down on their AP equivalent. Is it because Access is seen as easier?.

Michael,

Our users cannot produce their own reports - they require us to provide them in a finished format. Access does allow production of 'snapshot' reports that can then be attached to a email and sent. All achieved through code.

Anyway thanks again for your time.

Robert

 

[zemp]

EriRobert, everyone is somewhat bias to what they know and like, myself included. Obviously I know VB much better than I know Access therefore my choice would be to start with VB.

I try not to put down what I don't know because it does have it's place. Sorry If you got the wrong impression.

Best of luck to you.

Thanks and Good Luck!

zemp

 

[EriRobert]

zemp

No zemp I didn't mean you - you have been been fair - no question. I agree everyone is more comfortable with their 'home' software - and you can guess where my comfort is. As I said I haven't experienced the snobbery thing in this forum. Sorry that you thought that (I'd buy you a drink, but..).

Actually I though that coming into the Lions Den (VB Forum) with this question I'd get a rougher ride.

Robert

 

[Brian56]

>Access does allow production of 'snapshot' reports that can then be attached to a email and sent. All achieved through code.

in any reporting situation this is a big plus

 

[MichaelRed]

yes, but snapshot viewer is just another oiece which -although free- needs to be distribuited and 'maintained'. When all is said and done, there are no 'obvious' choices each soloution has it's strengths and weaknesses. Each needs to be judged in the arena of performance. What is the 'best' for a situation may not even be acceptable in another.




MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[mmusick]

Any comments if the backend is not SQL Server, but Oracle?

 

[vbSun]

Being in the Den as another "Lion" (or lamb..lol).. I will prefer VB over access as my development environment because of these reasons.

1. I know VB Better..
2. A program developed in VB, with an Access backend doesnt have the need for either software (VB and Access) to be in the client machine.
3. VB offers lot more control on interfaces, that an Access application. (I bliv, first impression really matters)
4. Easy to deploy.
5. Allows me to integrate Crystal Reports to it.. (i strongly think this is a big plus..).
6. Allows me to reuse many of my precompiled dlls (Splash screens, connection objects, progressbars, user login screens, custom message boxes..many to add..)
7. The VB IDE is far better than the Access IDE;
8. Easy to manage and share code with in a team of developers..

Here i am not talking about the relative merits and demerits, but just some points why i prefer developing a VB application to an Access application.

Or i may say i know how to do all these things in VB, it helps me develop my applications faster, and since am a terrible zero when it comes to doing these in Access, "VB Rocks!".

 

[DarenNM]

I usually use VB but have frequently programmed within Access for quick, one-off data updates.

As has been mentioned, you use the tool which works for you. I do prefer VB over Access though, as it tends to have more facilities (App object for example). Maybe this is because VB was designed as a programming language, whereas Access is a Database application with some (most) of the VBA language added in?

One thing that does annoy me about Access is that you can't get the value from a control unless it has the focus. Or am I missing something?


Must think of a witty signature

 

[MichaelRed]

DarenNM


" ... missing something ... " ~~ Missing a lot. Just my opinion of course, but "Application Object" is available in Ms. A. and VBA -across all members of the family- shares the same "Core" VB. It is only the app specific 'extensions' which vary and these are at least primarily references to the specific object model. You can, in fact, with little effort include the object libraries of other apps in Ms. A., just as you can with 'pure' VB and achieve the same level of integration.





MichaelRed
m.red@att.net

Searching for employment in all the wrong places

 

[DarenNM]

I'll look into it - thanks.


Must think of a witty signature

 

[T111]

I mostly use Access carrying on projects from a previous employee. I ran into a lot of problems with access and found it excellent and efficient for certain jobs but when the sugar hits the fan I think its inefficient and VB is a lot better especially if your project will be growing - as most do over time. The reports and other things like searching etc are a lot easier to implement in VBA but VB is a lot better - looks better and can easily connect to databases (not as easy as access), and can do a lot more a lot better. I am just starting to write a project in VB and like most projects it will probably expand over time and that’s when access can cause major problems. All in all its the work that needs to be done determines what programming tools you should use, but personally I find VB is better and once you get started and using VB the extra lines of code doesn’t seem to matter especially if you use modules. But examine what needs to be done, how it might change and how complicated it will be and then you should know what tool would be better. Access - short and simple projects, VB more complicated and c++ for the most difficult and the most complicated. That’s what I think anyway but I am just a newbie (out of college a few months) so maybe I might not be the best person to listen to.
Best of luck,
T111.

 

[strongm]

Well, in the early days of Access it was probably more clearcut, since AccessBasic was a very poor cousin of Visual Basic. However since MS switched to VBA in all their Office products this distinction has been significantly lessened almost to the point of non-existence.

Access lacks some of the additional tools etc included in the VB6 package, which makes it less suitable as a general purpose programming tool. On the other hand it includes stuff that makes it better when doing database work. It also has versions of controls that would have been nice to have in VB (many of the Forms 2.0 controls have some great properties and methods that the default equivalents in VB6 don't have)

The biggest downsides to VBA in Access is that it is interpreted, rather than compiled, and it is almost impossible to distribute an application to people who do not have Access installed if you are not using the Developer edition.