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:[color=blue]
>Per robert d via AccessMonster.com:[color=green]
>>I don't understand this concern since my front-end application will be linked
>>to a SQL SERVER backend.[/color]
>
>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.[/color]
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200602/1 
