VB6 And Access VS Access

[DS]

Is there any difference in network speed or anything else for that matter if
you use VB6 as a Front End and Access as a Back End as opposed to Access
Front End and Access Back End?
Thanks
DS

 

[Stuart McCall]

Is there any difference in network speed or anything else for that matter
if you use VB6 as a Front End and Access as a Back End as opposed to
Access Front End and Access Back End?
Thanks
DS

VB will be a tad slower as it doesn't have the Access query optimizer. Your
development will also take longer with VB because (eg) it doesn't have all
the built-in control properties that Access does. For instance there's no
BeforeUpdate and AfterUpdate events on textboxes. You must roll your own
(and that's not particularly easy to get just right).

 

[Albert D. Kallal]

Is there any difference in network speed or anything else for that matter
if you use VB6 as a Front End and Access as a Back End as opposed to
Access Front End and Access Back End?
Thanks
DS

The speed of the network or the client will not change one bit here. You can
write in in assembler for all that matters, the network does not know the
difference nor will run any faster.

Remember MS access is not processing bound here, but networks speed bound.
So, using assembler, c++, or ms-access to read data from a mdb file will not
change the speed of the jet database engine.

On the other hand for the most part any performance issues you encounter on
a network are going to be that as your application design.

I have the medium size application with about 30,000 lines of vBA code,
about 160 forms, and about 55 very highly related tables. On a typical
office network with five users the application absolute screams in terms of
performance. In fact we had replaced a $250,000 mainframe with a simple file
share (not even a database server!!). So, we not even running SQL server for
backend.

The trick in most cases is simply to load up a form to one record. Then if
the table has a million records, or one record in it, the form load time
will be near instant. There's no reason you should not get absolute near
blistering performance and near instant form load times on a typical office
network, and this is regardless of how large your tables are.

It you not getting very high performance, then it won't help if you write an
assembler, C++ or ms-access to read that data.

Unless your network is unreasonably slow, or you have a large users (say 25
or more), there's little if any reason that your application should not be
snappy and forms should not load instantly.

Often we do find that some of these visual basic applications run faster,
and that's because the developer designs the application to load a form up
to only the one record and not pull in a large number of records (and, so
many access developrs do this wrong). There is nothing wrong with using
bound forms, but you always want open forms with a "where" clause to
restrict the record being opened.

 

[DS]

Seems like a lot of extra work for the same results!
Thanks
DS

 

[DS]

Thanks Albert. Very informative. My database is slightly larger than the
one you discribed with nowhere near 25 concurrent users, usually one to 12
at the most. Like I said I'm using unbound forms where the reord isn't
commited untill the user clicks on the save button. So with all being said
and done I think I should be OK as far as speed goes. Thank you once again.
DS

 

[Mike Painter]

Seems like a lot of extra work for the same results!
Thanks
DS

Exactly. Be lazy.
VB is powerful and you may find a point where you have to pick between
buying a control that will do what you want and rolling your own.
Then VB gets interesting.