[AccessD] Distribution - a bit OT

Jim Lawrence (AccessD) accessd at shaw.ca
Sat May 31 07:50:56 CDT 2003


Hi Guys:

The one big problem I have always had converting Access to VB is the Access
automated SubForm interface that is just great with Invoicing systems. With
VB I have found of no easy way to duplicate these feature other than with
brute force programming or getting the client to buy a TB Grid component for
their site.

I have some great interfaces, created, using a combination of
DBgrid/Flexgrids, arrays and lots of programming. Do you have a better way
or is there something I have been over-looking all these years?

Jim

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Drew Wutka
Sent: Saturday, May 31, 2003 3:56 PM
To: 'accessd at databaseadvisors.com '
Subject: RE: [AccessD] Distribution - a bit OT


Paul, the problem you ran into was something that should occur at the
beginning of a job proposal.  If they don't want Access, you have two
options.  Sell it to them.  That can be pretty difficult, but it's not
necessarily impossible.  Explain the benefits, etc.  Two, build it in
something else.  Personally, I develop a lot of stuff in VB just as fast as
I would in Access, or at least close.

The big clash with Access is solved with VB.  Installing a runtime version
of Access 97 will definitely clash with a previous installation of Access 2k
or XP, or any future version.  That gives your Access applications a smudge,
a special consideration smudge.  Since bound applications can be built
extremely fast in Access, the development expense should outway that issue.

VB does not have the compatibility issue.  Installing VB 5.0 applications on
a machine that VB 6 applications have no issue, same with .Net.  So you can
install it and walk away.  The only issue you may have is if a future OS
does not support VB applications...but that is a long time away.  VB can use
.mdb's through ADO or DAO, which install on their own.  Newer ADO/DAO
versions can use previous .mdb versions, so that isn't an issue either.

Drew

-----Original Message-----
From: Paul Black
To: accessd at databaseadvisors.com
Sent: 5/31/03 2:59 PM
Subject: [AccessD] Distribution - a bit OT

Hi

I submitted a proposal to a client this week for a custom application.
Their
nose is a bit bent out of shape because they feel they should be able to

slap a CD in the drive click the install button and the app will install
in
a nice self-contained thing-a-ma-bob (that is what they said).

Why do we have to have MS Access installed? You don't, I said, I can
supply
a runtime version.

Why do we have to worry about what version of MS Access is installed
already? We did not ask for MS Access, we asked for a custom computer
application.

Why do we have to worry about installing a runtime version on a machine
with
Access already on it and causing all kinds of problems (paraphrased)?

Plain and simple they want an app that is a DBS management system but
they
want something that is completely autonomous. What do I do? What would
you
do? I may have already lost this deal but need to prepare for the next
time
this happens.

Do I offer a solution that is all VB or C++ or some such thing or am I
missing the boat here. Please help.


Thanks

PB

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list