Help in proving that Access is an industrial strength front-end

[robert d via AccessMonster.com]

I was asked to provide a proposal. I provided a proposal on my application
and the prospective client likes what I have but is wary of it having been
developed in Access.

I don't understand this concern since my front-end application will be linked
to a SQL SERVER backend.

But there seems to be this "conventional wisdom" among IT people that Access
is a toy database. Okay, let's redefine that as "Jet" is a toy database
(which I don't agree with but I'm trying to sell my front end). I don't think
people realize how powerful Access is. I recently showed my app to a
prospective subcontractor and they were amazed at what can be done in Access.

Okay, I'm probably preaching to the choir.

Can some experienced posters here help me put together a case that Access is
an industrial strength application as a front-end. If anyone knows of major
applications (particuarly if they are well known) that were developed in
Access that woud be great. Any relevant papers, articles, case studies,
statistics would be great. I need to present more than just words and my
assurances.

Any other advice, suggestions is greatly appreciated.

Thank you.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[Rick Brandt]

robert d via AccessMonster.com wrote:

I was asked to provide a proposal. I provided a proposal on my
application and the prospective client likes what I have but is wary
of it having been developed in Access.

I don't understand this concern since my front-end application will
be linked to a SQL SERVER backend.

But there seems to be this "conventional wisdom" among IT people that
Access is a toy database. Okay, let's redefine that as "Jet" is a toy
database (which I don't agree with but I'm trying to sell my front
end). I don't think people realize how powerful Access is. I recently
showed my app to a prospective subcontractor and they were amazed at
what can be done in Access.

Okay, I'm probably preaching to the choir.

Can some experienced posters here help me put together a case that
Access is an industrial strength application as a front-end. If
anyone knows of major applications (particuarly if they are well
known) that were developed in Access that woud be great. Any
relevant papers, articles, case studies, statistics would be great.
I need to present more than just words and my assurances.

Any other advice, suggestions is greatly appreciated.

Thank you.

The "conventional wisdom" prejudice is very real unfortunately. My strategy
would be three-fold.

1) Instead of trying to prove what Access can do ask them for objective evidence
for things (they think) it cannot do.

2) Explain that a non-Access solution can be done but that it could easily cost
ten times as much to develop.

3) Provide a small sample piece of functionality that their app requires
prototyped in Access with a full detail of how long it took to create.
Accompany that with an estimate of how long it will take to produce the same
prototype in anything else. If they want the latter then produce it for them
and when finished ask them if they can see any bang for the additional bucks
when comparing it to the Access solution.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[robert d via AccessMonster.com]

I was provided with the following link, which provides a substantial amount
of information. Hopefully others will find it useful.

http://www.fmsinc.com/tpapers/genaccess/DBOD.asp
Still looking for more justification particularly large apps that might have
been written in Access.

Rick Brandt wrote:

I was asked to provide a proposal. I provided a proposal on my
application and the prospective client likes what I have but is wary

[quoted text clipped - 22 lines]

Thank you.

The "conventional wisdom" prejudice is very real unfortunately. My strategy
would be three-fold.

1) Instead of trying to prove what Access can do ask them for objective evidence
for things (they think) it cannot do.

2) Explain that a non-Access solution can be done but that it could easily cost
ten times as much to develop.

3) Provide a small sample piece of functionality that their app requires
prototyped in Access with a full detail of how long it took to create.
Accompany that with an estimate of how long it will take to produce the same
prototype in anything else. If they want the latter then produce it for them
and when finished ask them if they can see any bang for the additional bucks
when comparing it to the Access solution.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[Rick Brandt]

"robert d via AccessMonster.com" <u6836@uwe> wrote in message
news:5bf23f0129515@uwe...

I was provided with the following link, which provides a substantial amount
of information. Hopefully others will find it useful.

http://www.fmsinc.com/tpapers/genaccess/DBOD.asp
Still looking for more justification particularly large apps that might have
been written in Access.

Large apps are typically written by large development teams and in that
environment you are just not going to have the leader of the effort suggest
using Access. Decision makers are simply not going to be fed information that
would lead them to that decision and if they somehow did their development team
would have none of it.

Large Access apps typically started small and were successful enough to outgrow
their humble beginnings.

I'm sure there are exceptions to these generalities, but I don't know where you
would find them. If there are enterprise level Access apps supporting large
(fortune 500 type) companies they are not likely to be bragging about that fact
(conventional wisdom being what it is).

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[robert d via AccessMonster.com]

Good point.

Rick Brandt wrote:

I was provided with the following link, which provides a substantial amount
of information. Hopefully others will find it useful.

[quoted text clipped - 3 lines]

Still looking for more justification particularly large apps that might have
been written in Access.

Large apps are typically written by large development teams and in that
environment you are just not going to have the leader of the effort suggest
using Access. Decision makers are simply not going to be fed information that
would lead them to that decision and if they somehow did their development team
would have none of it.

Large Access apps typically started small and were successful enough to outgrow
their humble beginnings.

I'm sure there are exceptions to these generalities, but I don't know where you
would find them. If there are enterprise level Access apps supporting large
(fortune 500 type) companies they are not likely to be bragging about that fact
(conventional wisdom being what it is).

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[Lyle Fairfield]

There are many people who think they know how to do Access. Most of
their work is just crap. A lot of that appears in Newsgroups like this
one. It's little wonder that other professionals have such a poor
opinion of the product. If I were dealing with a client such as you
describe I would try to persuade him and his IT department that there
is Access, and there is Access, and that the two are quite distinct
entities. I would also try to demonstrate with samples of my work that
I did the one kind and not the other. And I would point out that the
skills of analysis and problem solving are much more important to any
solution than the platform used.
If I were the client and you couldn't convince me of these things I
wouldn't go with Access.
I would be extremely reluctant to quote someone like Luke, who is
promoting his own product (which in my opinion is totally redundant for
the capable developer) through his promotion of Access.

[salad]

robert d via AccessMonster.com wrote:

I was asked to provide a proposal. I provided a proposal on my application
and the prospective client likes what I have but is wary of it having been
developed in Access.

I don't understand this concern since my front-end application will be linked
to a SQL SERVER backend.
What other front-ends to SQL Server are being proposed? Is SQL Server
both a back and front end? I didn't think so but maybe that's changed.
Or are they talking VB?

Do they do a lot of reports? Compare CrystalReports to creating an
Access report. The Access report writer is quite good.
But there seems to be this "conventional wisdom" among IT people that Access
is a toy database. Okay, let's redefine that as "Jet" is a toy database
(which I don't agree with but I'm trying to sell my front end). I don't think
people realize how powerful Access is. I recently showed my app to a
prospective subcontractor and they were amazed at what can be done in Access.
Are they using Office in any part of their application? Access is a
part of Office and thus more integrated to the other Office applications
than a non-office program. That might be a selling point.
Okay, I'm probably preaching to the choir.

Can some experienced posters here help me put together a case that Access is
an industrial strength application as a front-end. If anyone knows of major
applications (particuarly if they are well known) that were developed in
Access that woud be great. Any relevant papers, articles, case studies,
statistics would be great. I need to present more than just words and my
assurances.

Any other advice, suggestions is greatly appreciated.

Thank you.

[Br]

Lyle Fairfield wrote:

There are many people who think they know how to do Access. Most of
their work is just crap. A lot of that appears in Newsgroups like this
one. It's little wonder that other professionals have such a poor
opinion of the product.
I think most IT people hate Access because they are the ones stuck with
supporting everyone's inhouse, non-professional attempted databases (many
build with an Excel mindset).
If I were dealing with a client such as you
describe I would try to persuade him and his IT department that there
is Access, and there is Access, and that the two are quite distinct
entities.
Rather, there is amateur "hacks" and there is professional, properly
designed databases systems... (and a lot of middle ground:)

Having an SQL backend pretty much removes many of their hesitations with
using Access anyway...
I would also try to demonstrate with samples of my work that
I did the one kind and not the other.

Yup. Get them in contact with some happy current users.

<>
--
regards,

Br@dley

[(PeteCresswell)]

Per robert d via AccessMonster.com:

I don't understand this concern since my front-end application will be linked
to a SQL SERVER backend.

I haven't actually worked as an IT employee for about 15 years now... but I
still work hand-in-hand (sometimes hand-in-throat...) with IT on some
of my projects, so I am mindful of the perspective of many IT people.

One part of MS Access' bad rep is the fact that IT gets stuck with maintaining
applications that users with no IT experience have written - and a lot of
those are *really* ugly...

Another contributor is contractors like me who go in, develop an app at less
that a tenth (sometimes *much* less...) of the cost IT would have billed
an then leave the users to rave about what great service they got from me
and what a bunch of unresponsive bums the IT people are. Much of this,
of course, is a bad rap. I get to work in a quiet place, in intimate
contact with the users. For the most part, I am freed from whatever
onerous development methodologies that are imposed on IT people.
I don't have any other responsibilities, and I'm totally focused.
As a contractor, I am running scared to a certain extent - or at least much
more anxious about my client's state of mind than somebody in a different
relationship.

Finally, a significant problem is that IT people think that MS Access is a
desktop/file-based database; whereas actually it is a front end development
environment that happens to be bundled with the MS JET file-based dab abase
engine - but can be pointed to almost any back end that anybody can imagine. It
doesn't help any that both front ends and back ends have the same .MDB
extension and it's possible for people to embed tables into a front end.

But even if IT were to understand correctly what MS Access really is,
certain downsides remain:
---------------------------------------------------------------------------
1) Distribution: Somebody has to make sure the PCs of all who use the app
have the right version of MS Access installed. This can be a moving
target (per #2).

2) Vulnerability to MS Office upgrades: Another spin on #1. The LAN guys
decide to roll out a new release of MS Office, and your users suddenly
have problems. Nothing that can't be fixed easily and quickly - but
they *do* have to be fixed and with a mission-critical app the downtime
may not be acceptable and, even in the least-bad cases, will give IT
a black eye.

3) Modularity: Somebody will say that they've developed MS Access apps
with a team of 20 people, but from IT's perspective it is not suited
to large development projects. With, say, VB6 or .NET, you can
divide the code up into modules that can be checked in and out of
whatever code-control tool is used. Team development is doable
with MS Access, but harder. It doesn't match up with the model
that IT is used to working within, and the scalability is still less.

4) Consistency: MS Access development is significantly different from
VB or .NET development. Just because somebody can write in VB or
.NET does not mean they will be competent to develop or maintain
and MS Access app. I've cleaned up after a few of these.
IT's dream is one language/development environment for all their
apps. Not gonna happen, I know, but why add yet another?

5) Installation of new versions of the app: A non-issue somebody knows
how to go about it... but IT typically does not know and the method
differs from the model they use for everything else.

6) Corruption of the app: MS Access databases (in this case,
your front end) do get corrupted from time to time.
Not often, but it happens. Another source of potential
black eyes for IT.

7) Hired help: VB/.NET developers are a dime a dozen and the boys and
girls in Bangalore breathe fire, walk on water, and work cheap.

Even if nobody goes offshore, it's easier to find a competent
VB or .NET developer than an competent MS Access developer.
From an IT perspective, what the heck is a competent MS Access developer
anyhow? How do I (if I were an IT guy) recognize one?
----------------------------------------------------------------------------

There are upsides - like speed of delivery, 1/3 or even 1/20th of the billable
hours, no risk of loss of source code, and so-forth. But if the client
is not focused on development cost and IT is doing the job, the decision
to use VB or .NET instead seems pretty close to being a no-brainer.

OTOH, if the client *is* focused on development costs; a conservative estimate
against VB6 would be 1/3 of the man hours and 1/5th would not be much of
a stretch. Against .NET, based on two projects I've seen done both ways,
I'd say 1/10th or 1/20th... or even less.
I do MS Access... period. I'll point my apps at an SQL Server back end if
I think it's warranted and the clients buy in to the additional cost... but
Access is what I do.

But I would not want to try to sell a potential client on something that
will not be in their interest long-run. Maybe if I get hungrier, I'll
back off on this - but for now I tell each client all of the above before
they decide to take me on.
--
PeteCresswell

[Jeremy Wallace]

I work on a team with six developers, four in one office and two out of
their homes. We have a database that is an Access (.adp) front end and
a SQL Server back end. We use Visual Source Safe for version control,
Jira for bug tracking, Confluence for our design documents.

It's got over 1,200 data objects, 300 forms, 70 modules.

Big enough? <g>

Jeremy
--
Jeremy Wallace
Fund for the City of New York
http://metrix.fcny.org

Rick Brandt wrote:

"robert d via AccessMonster.com" <u6836@uwe> wrote in message
news:5bf23f0129515@uwe...

I was provided with the following link, which provides a substantial amount
of information. Hopefully others will find it useful.

http://www.fmsinc.com/tpapers/genaccess/DBOD.asp
Still looking for more justification particularly large apps that might have
been written in Access.

Large apps are typically written by large development teams and in that
environment you are just not going to have the leader of the effort suggest
using Access. Decision makers are simply not going to be fed information that
would lead them to that decision and if they somehow did their development team
would have none of it.

Large Access apps typically started small and were successful enough to outgrow
their humble beginnings.

I'm sure there are exceptions to these generalities, but I don't know where you
would find them. If there are enterprise level Access apps supporting large
(fortune 500 type) companies they are not likely to be bragging about that fact
(conventional wisdom being what it is).

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[robert d via AccessMonster.com]

Pete:

Thanks for the response. It turns out that we were not planning to develop
in Access but did as a workaround for a client who has a policy that does not
allow users to install .exes on their computers. However, all users have MS
Office Professional; hence with Access we work around this problem.

Here's my question: The app we develop has virtually no bound forms. Even
though we are using DAO, when we connect to SQL Server located on a server
the response is significantly faster than connecting to Jet located on a
server.

Is the fact that virtually all of our forms are unbound an advantage for the
points that I'm trying to make. For us, Access was only a front-end
development tool and a container that allows us to run our app on computers
that have been 'locked down'.

(PeteCresswell) wrote:

Per robert d via AccessMonster.com:

I don't understand this concern since my front-end application will be linked
to a SQL SERVER backend.

I haven't actually worked as an IT employee for about 15 years now... but I
still work hand-in-hand (sometimes hand-in-throat...) with IT on some
of my projects, so I am mindful of the perspective of many IT people.

One part of MS Access' bad rep is the fact that IT gets stuck with maintaining
applications that users with no IT experience have written - and a lot of
those are *really* ugly...

Another contributor is contractors like me who go in, develop an app at less
that a tenth (sometimes *much* less...) of the cost IT would have billed
an then leave the users to rave about what great service they got from me
and what a bunch of unresponsive bums the IT people are. Much of this,
of course, is a bad rap. I get to work in a quiet place, in intimate
contact with the users. For the most part, I am freed from whatever
onerous development methodologies that are imposed on IT people.
I don't have any other responsibilities, and I'm totally focused.
As a contractor, I am running scared to a certain extent - or at least much
more anxious about my client's state of mind than somebody in a different
relationship.

Finally, a significant problem is that IT people think that MS Access is a
desktop/file-based database; whereas actually it is a front end development
environment that happens to be bundled with the MS JET file-based dab abase
engine - but can be pointed to almost any back end that anybody can imagine. It
doesn't help any that both front ends and back ends have the same .MDB
extension and it's possible for people to embed tables into a front end.

But even if IT were to understand correctly what MS Access really is,
certain downsides remain:
---------------------------------------------------------------------------
1) Distribution: Somebody has to make sure the PCs of all who use the app
have the right version of MS Access installed. This can be a moving
target (per #2).

2) Vulnerability to MS Office upgrades: Another spin on #1. The LAN guys
decide to roll out a new release of MS Office, and your users suddenly
have problems. Nothing that can't be fixed easily and quickly - but
they *do* have to be fixed and with a mission-critical app the downtime
may not be acceptable and, even in the least-bad cases, will give IT
a black eye.

3) Modularity: Somebody will say that they've developed MS Access apps
with a team of 20 people, but from IT's perspective it is not suited
to large development projects. With, say, VB6 or .NET, you can
divide the code up into modules that can be checked in and out of
whatever code-control tool is used. Team development is doable
with MS Access, but harder. It doesn't match up with the model
that IT is used to working within, and the scalability is still less.

4) Consistency: MS Access development is significantly different from
VB or .NET development. Just because somebody can write in VB or
.NET does not mean they will be competent to develop or maintain
and MS Access app. I've cleaned up after a few of these.
IT's dream is one language/development environment for all their
apps. Not gonna happen, I know, but why add yet another?

5) Installation of new versions of the app: A non-issue somebody knows
how to go about it... but IT typically does not know and the method
differs from the model they use for everything else.

6) Corruption of the app: MS Access databases (in this case,
your front end) do get corrupted from time to time.
Not often, but it happens. Another source of potential
black eyes for IT.

7) Hired help: VB/.NET developers are a dime a dozen and the boys and
girls in Bangalore breathe fire, walk on water, and work cheap.

Even if nobody goes offshore, it's easier to find a competent
VB or .NET developer than an competent MS Access developer.
From an IT perspective, what the heck is a competent MS Access developer
anyhow? How do I (if I were an IT guy) recognize one?
----------------------------------------------------------------------------

There are upsides - like speed of delivery, 1/3 or even 1/20th of the billable
hours, no risk of loss of source code, and so-forth. But if the client
is not focused on development cost and IT is doing the job, the decision
to use VB or .NET instead seems pretty close to being a no-brainer.

OTOH, if the client *is* focused on development costs; a conservative estimate
against VB6 would be 1/3 of the man hours and 1/5th would not be much of
a stretch. Against .NET, based on two projects I've seen done both ways,
I'd say 1/10th or 1/20th... or even less.

I do MS Access... period. I'll point my apps at an SQL Server back end if
I think it's warranted and the clients buy in to the additional cost... but
Access is what I do.

But I would not want to try to sell a potential client on something that
will not be in their interest long-run. Maybe if I get hungrier, I'll
back off on this - but for now I tell each client all of the above before
they decide to take me on.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[robert d via AccessMonster.com]

Thanks, Jeremy:

I appreciate you making this information available to me.

Jeremy Wallace wrote:

I work on a team with six developers, four in one office and two out of
their homes. We have a database that is an Access (.adp) front end and
a SQL Server back end. We use Visual Source Safe for version control,
Jira for bug tracking, Confluence for our design documents.

It's got over 1,200 data objects, 300 forms, 70 modules.

Big enough? <g>

Jeremy
--
Jeremy Wallace
Fund for the City of New York
http://metrix.fcny.org

>I was provided with the following link, which provides a substantial amount
> of information. Hopefully others will find it useful.

[quoted text clipped - 22 lines]

to this message. Send instead to...
RBrandt at Hunter dot com

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[David W. Fenton]

"(PeteCresswell)" <[e-mail]> wrote in
news:i1********************************@4ax.com:

2) Vulnerability to MS Office upgrades: Another spin on #1. The
LAN guys
decide to roll out a new release of MS Office, and your users
suddenly have problems. Nothing that can't be fixed easily
and quickly - but they *do* have to be fixed and with a
mission-critical app the downtime may not be acceptable and,
even in the least-bad cases, will give IT a black eye.

This problem occurs because of stupidity -- the assumption that a
database application is just another document-based piece of
software is just bloody stupid. IT people should be smarter than
that.

But my experience is that many of the people who settle in IT jobs
are often incredibly stupid people, and quickly lose any edge they
might have had in keeping up-to-date on technologies and best
practices.

I am firmly convinced that most organizations would be better off
outsourcing their IT support to organizations in the business of
providing IT support to a wide range of businesses of all sizes.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"(PeteCresswell)" <[e-mail]> wrote in
news:i1********************************@4ax.com:

6) Corruption of the app: MS Access databases (in this case,
your front end) do get corrupted from time to time.
Not often, but it happens. Another source of potential
black eyes for IT.

Corruption of front ends seems to me to be extremely rare. I can't
think of the last time this happened to any of my clients. MS Office
program installations get corrupted more frequently than Access
MDBs, in my experience, and the solution to both in almost all cases
is to simply re-install (that always works for Access, and most of
the time for Office apps).

This ought to be a complete non-issue.

Now, if the back end is Jet, that's a different situation, but there
are administrative tasks that need to be performed on a regular
basis even with SQL Server, so why anyone would think you wouldn't
need to do any administrative maintenance on a Jet back end has
always mystified me completely.

And it's easy to avoid Jet back end corruption by migrating to a
server back end. Of course, that also increases the administrative
load, which is exactly why there are so many Jet back ends out
there.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@g47g2000cwa.googlegr oups.com:

There are many people who think they know how to do Access. Most
of their work is just crap.

My experience of being brought in as an Access developer to redo
projects started in VB or Delphi and so forth suggests to me that
most programmers are crap. The things I've seen in the apps I've
been asked to replace are pretty horrendous. It's quite clear that
those people had no business whatsoever developing database
applications at all. They knew nothing about proper database design
nor had a clue about good UI design.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[robert d via AccessMonster.com]

I'm going to ask a question which some may think is stupid, but I really need
the perspective. I haven't given this any thought, but if you don't develop
in Access what are the alternatives (let's ignore Enterprise Applications
like Oracle, SAP). I've heard of Delphi and VB6, which I assume are on a
comparable level with Access. What would be the next step up in terms of
sophistication? I assume everyone uses some type of development environment.
What's available and how do they rank in terms of perceived sophistication?

Thanks.

David W. Fenton wrote:

6) Corruption of the app: MS Access databases (in this case,
your front end) do get corrupted from time to time.
Not often, but it happens. Another source of potential
black eyes for IT.

Corruption of front ends seems to me to be extremely rare. I can't
think of the last time this happened to any of my clients. MS Office
program installations get corrupted more frequently than Access
MDBs, in my experience, and the solution to both in almost all cases
is to simply re-install (that always works for Access, and most of
the time for Office apps).

This ought to be a complete non-issue.

Now, if the back end is Jet, that's a different situation, but there
are administrative tasks that need to be performed on a regular
basis even with SQL Server, so why anyone would think you wouldn't
need to do any administrative maintenance on a Jet back end has
always mystified me completely.

And it's easy to avoid Jet back end corruption by migrating to a
server back end. Of course, that also increases the administrative
load, which is exactly why there are so many Jet back ends out
there.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[robert d via AccessMonster.com]

Okay. Here's another question, which some may think is stupid.

Since I want this project I'm looking to be flexible but at a reasonable cost.
I was thinking that if after I present the arguments for Access and I still
sense resistance, I might offer to repackage my app in VB6 or whatever the
latest version is.

It's been a very long time since I've used VB. How difficult will it be to
repackage within VB bearing in mind that virtually all forms are unbound.

Thanks.

robert d wrote:

I'm going to ask a question which some may think is stupid, but I really need
the perspective. I haven't given this any thought, but if you don't develop
in Access what are the alternatives (let's ignore Enterprise Applications
like Oracle, SAP). I've heard of Delphi and VB6, which I assume are on a
comparable level with Access. What would be the next step up in terms of
sophistication? I assume everyone uses some type of development environment.
What's available and how do they rank in terms of perceived sophistication?

Thanks.

6) Corruption of the app: MS Access databases (in this case,
your front end) do get corrupted from time to time.

[quoted text clipped - 20 lines]

load, which is exactly why there are so many Jet back ends out
there.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[(PeteCresswell)]

Per David W. Fenton:

Corruption of front ends seems to me to be extremely rare. I can't
think of the last time this happened to any of my clients. MS Office
program installations get corrupted more frequently than Access
MDBs, in my experience, and the solution to both in almost all cases
is to simply re-install (that always works for Access, and most of
the time for Office apps).

This ought to be a complete non-issue.

I agree, but it *does* happen and IT still have egg on their face when it does -
so it would be another reason - no matter how small - that IT would distance
itself from developing an MS Access app.
--
PeteCresswell

[(PeteCresswell)]

Per robert d via AccessMonster.com:

I haven't given this any thought, but if you don't develop
in Access what are the alternatives (let's ignore Enterprise Applications
like Oracle, SAP). I've heard of Delphi and VB6, which I assume are on a
comparable level with Access.

Dunno from Delphi, Oracle, or SAP. VB6 is on a similar level with MS Access
development-complexity-wise (assuming you aren't going to use bound forms, bound
controls, and wizards on the MS Access app). However it's a step up
billable-hour-wise by a factor of 3 to five times depending on who you ask.

A VB6 app is also inherently different in that it is compiled/linked to exist as
a separate thing from the source code.

Next step up from VB6 is .NET.
--
PeteCresswell

[HK]

Another data centric developement tool is Visual Foxpro. But I think
..NET would be a better alternative.

[salad]

David W. Fenton wrote:

"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@g47g2000cwa.googlegr oups.com:

There are many people who think they know how to do Access. Most
of their work is just crap.

My experience of being brought in as an Access developer to redo
projects started in VB or Delphi and so forth suggests to me that
most programmers are crap. The things I've seen in the apps I've
been asked to replace are pretty horrendous. It's quite clear that
those people had no business whatsoever developing database
applications at all. They knew nothing about proper database design
nor had a clue about good UI design.

I think it was my second application that I came in on. A
programmer/CPA had written it. A person placed an order. The customer
paid for the order over 12 months. The way the application was written,
if the person didn't pay, after a month, the invoice amount was deducted
by 1/12. If a person didn't pay in the entire 12 months, he owned
nothing. I understood why the person was losing money.

[Tim Marshall]

David W. Fenton wrote:

My experience of being brought in as an Access developer to redo
projects started in VB or Delphi and so forth suggests to me that
most programmers are crap. The things I've seen in the apps I've
been asked to replace are pretty horrendous. It's quite clear that
those people had no business whatsoever developing database
applications at all. They knew nothing about proper database design
nor had a clue about good UI design.

As a manager in a maintenance organization who is inextricably involved
with database transactions and historical analysis, I've found a
disturbing trend somewhat related to the above. Mostly it's not so much
that programmers are crap (I can't really judge this, except in VBA type
projects) but that many programmers I've encountered haven't got a
frakking clue about databases, especially in the areas of structure
design and normalization. It's quite shocking, really.

I've found a lot of temp help we've had in our organization that come
from numerous community colleges that blare across the television and
radio about "making you an IT expert!" knew little about proper database
design (it didn't matter to me about platform experience, just the
ability to understand db concepts) and seemed to be imbued with a
spreadsheet mentality.

My worst example: A number of years ago, we had a purchasing project
given to our university programming department. It was supposed to be
integrated with the maintenance management system I run and the
university's purchasing system and was an Oracle back end with an Access
FE. The programmer had done one of these before for another department.
The programmer did not make any real effort to find out how our
maintenance system worked, how the location information from the same
maintenance the programmer was supposed to be linking to was organized
nor how the university purchasing system worked. The result was
stupendously bad and it took two bloody years to achieve - we never used
it. I submitted a list of 49 critical deficiencies - some of the worst
included:

Once a transaction began on screen, there was no way to cancel what you
were doing BEFORE it was submitted. To me, and the analogy I used in my
critique was that this was akin to clicking 'compose' on an email client
and then being unable to close without sending, ie, you would HAVE TO
send the email, completed or not.

Hand in hand with the above, there were NO constraints whatsoever (ie,
enforced referential integrity relationships), so the above and lots of
other events resulted in regularly orphaned records.

Combo boxes connected to work order numbers and room locations had no
means to be filtered resulting in thousands or even 100s of thousands of
records presented in a combobox at one time.

Coding was horrendous. Variables were dimmed all over a procedure,
there was no consistent format, ie, an If statement's end if would be
way the heck over to the right and impossible to find.

I had not been allowed to help this programmer for various stupid
political reasons, although I tried to at first and think it would have
been a good learning experience for the programmer as well as for me (I
don't know everything, not by a long shot). The sad part was the
programmer was a really nice person and had taken the project on hoping
we'd work together on it. Two years later for something that should
have taken 4 months, maybe 6 months tops, and we abandoned the effort.
The computer department would not address my 49 criticisms and I've been
a pariah with them ever since. Oh well...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

"robert d via AccessMonster.com" <u6836@uwe> wrote in
news:5bfc230a1f51c@uwe:

Here's my question: The app we develop has virtually no bound
forms. Even though we are using DAO, when we connect to SQL
Server located on a server the response is significantly faster
than connecting to Jet located on a server.

Are you comparing apples to oranges here? That is, is the Jet back
end also using unbound forms and DAO? I would expect performance to
be similar, except where the data requests has large numbers of
records in it (such as when you're doing summaries of large data
sets). For data editing, you'd always be retrieving only 1 record
(or a handful of records), so I wouldn't expect to see any
significant difference between Jet and SQL Server as back end with
unbound forms.

I wouldn't expect much difference with properly filtered bbound
forms, either, what Larry and I in this newsgroup call "semi-bound"
forms, where the recordsource is repeatedly changed to retrieve only
1 or a small number of records, but all the controls on the form are
still bound to the data source.

I don't like the term "semi-bound" any longer, as it's completely
bound in all senses, but that's what we've called it in the past. I
think the reason for calling it that is to make the point that
almost always the main performance banefit of going to an unbound
form comes from the fact that you're loading only a single record
(as compared to a traditional Access form bound to a full table).
When you change the recordsource to retrieve only one record, you're
getting all that performance benefit without all the extra work it
takes to make the form unbound (it's not populating and saving the
data that's hard in an unbound form -- it's losing all the events
that are associated with bound records, such as, Me.Dirty, for
instance).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"robert d via AccessMonster.com" <u6836@uwe> wrote in
news:5bfcb447508dc@uwe:

I'm going to ask a question which some may think is stupid, but I
really need the perspective. I haven't given this any thought,
but if you don't develop in Access what are the alternatives
(let's ignore Enterprise Applications like Oracle, SAP). I've
heard of Delphi and VB6, which I assume are on a comparable level
with Access. What would be the next step up in terms of
sophistication?

It depends on what you mean by "step up in sophistication." If you
mean and IDE that has sophisticated tools for creating
database-driven applications, there is simply nothing that is more
sophisticated than Access itself.

The alternative development tools are more versatile because they
are not designed around building database applications, but around
building applications in general. This means they lack many
high-level features that Access offers. The result is that if you
are building a database application in another programming
environment you have to recreate many of the things that Access
offers by default.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"robert d via AccessMonster.com" <u6836@uwe> wrote in
news:5bfcd1dca29b8@uwe:

Since I want this project I'm looking to be flexible but at a
reasonable cost. I was thinking that if after I present the
arguments for Access and I still sense resistance, I might offer
to repackage my app in VB6 or whatever the latest version is.

It's been a very long time since I've used VB. How difficult will
it be to repackage within VB bearing in mind that virtually all
forms are unbound.

Why would you use Access if you're going to use all unbound forms?
That's completely senseless, and it seems to me always comes from a
mindset that either resists the capabilities of Access or simply
doesn't understand them in the first place.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

"(PeteCresswell)" <[e-mail]> wrote in
news:m9********************************@4ax.com:

Per David W. Fenton:

Corruption of front ends seems to me to be extremely rare. I can't
think of the last time this happened to any of my clients. MS
Office program installations get corrupted more frequently than
Access MDBs, in my experience, and the solution to both in almost
all cases is to simply re-install (that always works for Access,
and most of the time for Office apps).

This ought to be a complete non-issue.

I agree, but it *does* happen and IT still have egg on their face
when it does - so it would be another reason - no matter how small
- that IT would distance itself from developing an MS Access app.

But the main reason IT would have egg on their face is:

1. they are not using good quality equipment have have bad NICs, bad
wiring, bad switches, etc.

2. they are not maintaining the software environment on client PCs
correctly and are allowing patched versions of Acces to revert to
pre-patched versions.

3. they are ignoring the needs of Jet data files stored on a file
server by installing things on the file server that can interfere
with Jet (such as AV monitoring that scans MDB files).

All of those are IT's errors, and they deserve to have egg on their
faces for them.

If all of those things are done properly, the only thing that will
corrupt Access data (front ends are fungible, so irrelevant) is a
messy shutdown of a workstation, either a crash or a user shutting
down during an edit. Even those corruptions are almost always very
easily recovered from, since the data really isn't corrupted, just
marked as suspect. Indeed, in most cases, it's only the user who
crashed/shut down who is the only one who will be informed of a
corruption.

Keep the workstations running smoothly (an IT responsibility) and
train users not to shut down (perhaps an IT responsibility, too),
and this won't happen often enough to worry about.

It certainly doesn't happen to any of my clients.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[(PeteCresswell)]

Per David W. Fenton:

Why would you use Access if you're going to use all unbound forms?
That's completely senseless, and it seems to me always comes from a
mindset that either resists the capabilities of Access or simply
doesn't understand them in the first place.

I did bound forms at first, but started doing mostly unbound after a couple of
years.

I could go both ways, but maintenance-wise it seems simpler to stick with one
approach or the other.

Unbound forms do involve writing more code, but the additional code is pretty
much simple/rote stuff.

With unbound forms I see:
----------------------------------------------------------------------------
1) More straightforward coding when the Browse/Edit/Cancel/Commit model is
being used and a newly-added parent record's PK has to be captured
for use on child records under that model. Definitely *more* coding,
but it's simple coding - no tricks needed.

2) Better support for edit checking - especially when values in a new
record need to be cross-checked against various properties of existing
records or validated against the values in other child records being
added at the same time.

3) Less chance for database corruption.

4) Less chance for users to butt heads over the same block of data.

5) The ability to log detailed information about who changed what on a complex
form.

6) Better scalability from .MDB to SQL Server back end. Just replace the
queries used to pipeline data to the unbound form with stored procedures
in the DB.
-----------------------------------------------------------------------------
--
PeteCresswell

[David W. Fenton]

"(PeteCresswell)" <[e-mail]> wrote in
news:a8********************************@4ax.com:

With unbound forms I see:

I use unbound forms to add new records, but only bound forms for
editing. This works very well.

I've never really found the Browse/Edit/Cancel/Commit model to be
user-friendly. It feels to me like a throwback to mainframe terminal
days, rather than a modern graphical interface.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[robert d via AccessMonster.com]

The reason we went to Access is that our major client does not allow
executables to be installed by users and we do not want to go through the
software certification process for only 10 to 20 users. Since every user has
Office Professional, we can get around these roadblocks by using Access.

In addition, we have noted the advantages of unbound forms posted by Pete.

David W. Fenton wrote:

Since I want this project I'm looking to be flexible but at a
reasonable cost. I was thinking that if after I present the

[quoted text clipped - 4 lines]

it be to repackage within VB bearing in mind that virtually all
forms are unbound.

Why would you use Access if you're going to use all unbound forms?
That's completely senseless, and it seems to me always comes from a
mindset that either resists the capabilities of Access or simply
doesn't understand them in the first place.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1

[David W. Fenton]

"robert d via AccessMonster.com" <u6836@uwe> wrote in
news:5c43b3be1cbc2@uwe:

In addition, we have noted the advantages of unbound forms posted
by Pete.

I think the conventional wisdom on how great unbound forms are is
one of those "Emperor has no clothes" situations. Unbound forms have
their uses, yes, but they don't belong everywhere. I can't stand
giving up the .Dirty property of forms. Yes, there are a number of
ways to figure out if the data in an unbound form has been changed,
but none of them are as elegant or as reliable as the .Dirty
property with a bound form. And that's just the beginning of what
you give up when you go unbound.

I don't think it's worth it, given the incredible amount of code you
have to write to get back the things you had in a bound form with no
code at all.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Lyle Fairfield]

I pay about $100 for Access:
$40 for bound forms:
$40 for linked subforms;
$40 for reports;
The rest is worthless.
But then I get a $20 (I think it should be larger!) rebate because I
have to take VBA, argghhhhhhhhh.
All in all, it's a great deal!

So I give up bound forms, and that makes linked subforms half as
powerful as previously.

And now I'm left with $40 value on a $100 investment. No thanks, nor
for me! Why spoil a good thing?

BTW, what per cent of all questions here are from people who have
decided they know how to do things a lot better than the Access way,
and have created something half-way between a travesty and tragedy?

[rkc]

Lyle Fairfield wrote:

BTW, what per cent of all questions here are from people who have
decided they know how to do things a lot better than the Access way,
and have created something half-way between a travesty and tragedy?

Travesty and tragedy usually begin with a less than stellar db design.
Unbound forms are a side effect. You can't link the unlinkable.

[(PeteCresswell)]

Per Lyle Fairfield:

the Access way

?
--
PeteCresswell

[Larry Linson]

"(PeteCresswell)" <[e-mail]> wrote

Per Lyle Fairfield:

the Access way

?

It's kind of like "The Zen Way," Pete, only different. :-)

If you are a fan of Heinlien: to really get the most out of Access, you have
to "grok" it.

But, to me, that just means you need to learn how Access naturally works and
adapt your development approach to that, rather than trying to force Access
to do something in a different way than it would naturally do.

One example we see of NOT following The Access Way is Excel users who
desperately want Access to be nothing more than a spreadsheet that will
handle more rows than Excel. They "commit spreadsheet" with the Access
database and, more often than not, end up tangled up in their own
shoestrings (or, perhaps, codestrings).

Larry Linson
Microsoft Access MVP

[David W. Fenton]

"Larry Linson" <bo*****@localhost.not> wrote in
news:_KKLf.7675$fU6.4902@trnddc08:

"(PeteCresswell)" <[e-mail]> wrote

Per Lyle Fairfield:

the Access way

?

It's kind of like "The Zen Way," Pete, only different. :-)

If you are a fan of Heinlien: to really get the most out of
Access, you have to "grok" it.

But, to me, that just means you need to learn how Access naturally
works and adapt your development approach to that, rather than
trying to force Access to do something in a different way than it
would naturally do.

I think the key issue is that you should approach Access like an
end-user, who doesn't want to do any programming, and build as much
of your app with the end-user tools, and add code and complexity
only for the things that are not accomplished easily with
point-and-click.

Coming to Access as I did from a Paradox for DOS background, this
was very easy for me to grasp (in PDOX/DOS, your code is just an
automated user of the user interface, like Lotus spreadsheet
macros).

I think that too many experienced programmers tend to reach for the
more complex solution without having actually exhaused the
functionality of the point-and-click approach.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Bob Alston]

David W. Fenton wrote:

"Larry Linson" <bo*****@localhost.not> wrote in
news:_KKLf.7675$fU6.4902@trnddc08:

"(PeteCresswell)" <[e-mail]> wrote

Per Lyle Fairfield:

the Access way

?

It's kind of like "The Zen Way," Pete, only different. :-)

If you are a fan of Heinlien: to really get the most out of
Access, you have to "grok" it.

But, to me, that just means you need to learn how Access naturally
works and adapt your development approach to that, rather than
trying to force Access to do something in a different way than it
would naturally do.

I think the key issue is that you should approach Access like an
end-user, who doesn't want to do any programming, and build as much
of your app with the end-user tools, and add code and complexity
only for the things that are not accomplished easily with
point-and-click.

Coming to Access as I did from a Paradox for DOS background, this
was very easy for me to grasp (in PDOX/DOS, your code is just an
automated user of the user interface, like Lotus spreadsheet
macros).

I think that too many experienced programmers tend to reach for the
more complex solution without having actually exhaused the
functionality of the point-and-click approach.

Well said, David!

And who cares if it is industrial strength anyway. The key is whether
it will work for the intended purpose and if you have the skill
necessary to build using it. Access makes the latter much easier than
other programming alternatives.

Bob