Access Back End, VB Front End -- Why? 
Author Message
 Access Back End, VB Front End -- Why?

And don't forget the great microsoft tradition of screwing the developer
with incompatable office updates about every 12 months... (give or take
schedule flux :-> )

D.

| In my experience Access apps are a disaster with more than a few users. The
| data traffic between the user and the database is intense, so the
| application is VERY sensitive to the network load; and as your customer has
| mentioned, extremely subject to data corruption.
|
| Using VB as a front end make the app independent of the database tool you
| use: you can start with an Access back-end, then upgrade to a something more
| powerful later if you need to. I'd also question your 'doubling the initial
| proposed price' -- Access makes it quick to create forms and reports, but in
| a serious app these are only a minor component anyway. Apart from that, VB
| amd VBA are pretty much alike. And in any case, installation, training and
| long-term support are likely to be MUCH greater costs than the initial code
| development. If you'd ever tried to support an Access application on a
| corporate network you wouldn't be asking this question!
|
| Access is great for quick-and-dirty development, prototypes, etc. But the
| savings are all short-term. Trawl through this and similar forums and you'll
| find any number of posts from people trying to convert Access apps to VB
| (and prepared to wear the expense of doing so). I've never yet seen anyone
| trying to go the other way.
|
|
|

| > I have a client for which I have proposed an Access 2000
| > database in a multiuser environment (about 20 users max).
| > The client is concerned about data corruption and record
| > locking issues usually associated with this number of
| > users and is insisting that I develop the front end in
| > VB.  Personally, I don't see that this should be a big
| > issue to the customer, but it seems to be a go/no-go gate
| > for them.
| >
| > Can you give me some rationalle that either supports the
| > customers argument, or that I can use to allay their
| > concerns.  Building a front end in VB will be very
| > expensive to the customer, probably doubling the initial
| > proposed price.
| >
| > Your insight is greatly appreciated.
| >
| > (You know about the nospam in the email address, if you
| > wish to reply directly to me.
| >
| > Best,
| >
| > Earl
|
|



Thu, 27 Jan 2005 05:06:37 GMT  
 Access Back End, VB Front End -- Why?
Marylin & dnagle,

Thanks to both of you for your candid replys.  I've just
spent about five hours going through this newsgroup and
picking out anything that looked relevant to my question
and a few other things I'm looking at.  (sorry, I'm on
dialup connection from home right now and I live in the
sticks.)  Here is my thinking.

I will be building the front end in VB6/ADO, since it is
easiest to upgrade this approach, should the customer ever
decide to use SQL Server in future.  

A local install of Jet 4.0 will be required on each user's
workstation.  Access is not a client/server DBMS.  As
such, all data processing will still be done at the local
client.  (I don't understand how this will cut down on
network traffic, but most others seem to think that VB on
the front is more stable than VBA.)  

I'm not sure how this will affect Access 97 users, and
that worries me a lot, because my reputation rides on
successful deployments.  I need to do some testing here,
before I tender the revised proposal.

I agree with you that creating forms and populating them
with controls is trivial, and that the power of any
application resides in the code beneath them.  It is just
that from a database perspective, Access has a much more
robust exposure of data oriented events that make coding
for their handling much simpler and more specific.  And
building queries and reports is a breeze in Access,
compared to VB.  I remain unconvinced with regard to
application development time.

In summary, A VB.exe is more stable and faster than
an .mdb front end, principally because the language has
been more rigorously applied to a wider variety of
applications than VBA, and because the application will be
a compiled executable, rather than a source file that must
be interpreted on the fly.  It will not substantially
decrease network traffic, since all data requests and
processing will continue to be handled on the local
machine, not on the server.  The application should
(theoretically) be independent of which version of Access
and Windows OS are running on each local machine, because
the deployment should include all referenced object
libraries required to run the application.  This also
makes it insensitive to future Office upgrades, as long as
the back-end continues to run under Office 2000.  Last,
using ADO should make it easier to later upgrade the back
end to SQL server with minimal code changes to the
application.

Again, thanks for your responses, and I look forward to
your lambasting me for any glowing errors I have made
above.

Best,

Earl

Quote:
>-----Original Message-----
>In my experience Access apps are a disaster with more

than a few users. The
Quote:
>data traffic between the user and the database is
intense, so the
>application is VERY sensitive to the network load; and as
your customer has
>mentioned, extremely subject to data corruption.

>Using VB as a front end make the app independent of the
database tool you
>use: you can start with an Access back-end, then upgrade
to a something more
>powerful later if you need to. I'd also question

your 'doubling the initial
Quote:
>proposed price' -- Access makes it quick to create forms
and reports, but in
>a serious app these are only a minor component anyway.
Apart from that, VB
>amd VBA are pretty much alike. And in any case,

installation, training and
Quote:
>long-term support are likely to be MUCH greater costs

than the initial code
Quote:
>development. If you'd ever tried to support an Access
application on a
>corporate network you wouldn't be asking this question!

>Access is great for quick-and-dirty development,

prototypes, etc. But the
Quote:
>savings are all short-term. Trawl through this and

similar forums and you'll
Quote:
>find any number of posts from people trying to convert
Access apps to VB
>(and prepared to wear the expense of doing so). I've

never yet seen anyone
Quote:
>trying to go the other way.



>> I have a client for which I have proposed an Access 2000
>> database in a multiuser environment (about 20 users
max).
>> The client is concerned about data corruption and record
>> locking issues usually associated with this number of
>> users and is insisting that I develop the front end in
>> VB.  Personally, I don't see that this should be a big
>> issue to the customer, but it seems to be a go/no-go
gate
>> for them.

>> Can you give me some rationalle that either supports the
>> customers argument, or that I can use to allay their
>> concerns.  Building a front end in VB will be very
>> expensive to the customer, probably doubling the initial
>> proposed price.

>> Your insight is greatly appreciated.

>> (You know about the nospam in the email address, if you
>> wish to reply directly to me.

>> Best,

>> Earl

>.



Fri, 28 Jan 2005 17:46:49 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Access Back End, VB Front End -- Why?

2. Packaging a VB front end/Access back end application

3. Trying to Create a communicator for VB.net Front End and SQL 2000 back end

4. VB Front end dll loses connection to back end SQL server db after an hour

5. Problem Connecting VB front end to C++ back end

6. A2k: Controlling a back-end MDB from its FRONT-end MDB

7. A2K Updating Back End with new fields from Front End

8. Compact the back-end data from the front-end

9. Corrupted back end corrputs all front ends!

10. Splitting db in front end and back end

11. Compact back-end front-end

12. Front-End & Back-End

 

 
Powered by phpBB® Forum Software