Access vs. QuickBooks Pro
Deborah V. Gardner
to maintain customer data for mailings, service orders and follow up, as
well as to maintain inventory. I have worked with both and developed
apps in Access. I know why I prefer Access and I realize that I am
asking a pretty biased group of people of their opinions.
So, if possible can any of you give me as unbiased as possible reasons
why to use one over the other to maintain customer data and/or
inventory?
Thank you,
Deborah
Rick Brandt
news:3E7A60F2...@twcny.rr.com...
I would expect that for the 99.9999% of people who would have a need for
this type of application and would have no idea how to create it themselves
with Access, the answer is obviously QuickBooks. For almost all of the
remainder, it would still be QB unless they either placed a very low value
on their time, or had very compelling needs for customization.
Now if I rubbed a magic lamp and the genie offered me an accounting package
written in Access that did nearly everything I needed and which I could
customize for the rest, I would prefer that over QB. However; I would never
take the time to write my own. Some wheels are not worth reinventing.
(Pete Cresswell)
I've been doing MS Access apps for about seven years.
My experience is that for any reasonably-complicated "real-world" application
200 manhours is about the bare minimum. That's a lot of bucks compared to a
couple hundred for QuickBooks. I'm (hopefully) in the home stretch of a
project/time management system that's up to 500 hours and will certainly hit 650
before it's finally wrapped up.
So: If QuickBooks can do 80% of what they need and they can live without the
other 20% I'd call it a no-brainer: Quickbooks.
-----------------------
PeteCresswell
Larry Linson
tired"* commercial accounting application, done in Access, available from
Database Creations, http://www.databasecreations.com, Cary Prague's company.
You get the Access source, so if you need to modify it, you can.
* for which read "time-tested and proven"
There are other accounting programs described, evaluated, and linked from
MVP Tony Toews' site, http://www.granite.ab.ca/accsmstr.htm.
You could take a look at these before deciding on Quick Books.
"Rick Brandt" <rvtjb...@sbcglobal.net> wrote in message
news:b5dqc7$28bjhd$1...@ID-98015.news.dfncis.de...
Steven R. Zuch
A more complete answer is determine what your client needs, and
ascertain if QuickBooks has the functionallity to handle it. If it
does, than it makes more sense to use it.
But QB does not contain a very sophisicated customer database for
storing non-accounting related information, nor do I believe it has
the ability to tract follow-up information to service orders
(depending how you define follow-up).
But if you need to integrate a complete inventory system (QB has a
good inventory system), it would be alot to write a complete inventory
system in Access, and integrate it with service orders and customer
sales information, etc ...
You my need to combine QB with one of their many add-on packages, or
look at other systems.
Steven R. Zuch
Cogent Management Inc.
Rick Brandt
that sitting in my desk drawer at work. I was asked to evaluate it several
years ago for possible customization for our company's field reps. The
project was axed before I spent much time with it though.
You know how it is though Larry. If I *can* customize it I wouldn't be able
to keep my anal-retentive hands off of it and would probably spend way too
much time "fiddling around". On an app that complex one could easily waste
a lot of time even with all of the real work already done.
"Larry Linson" <larry....@ntpcug.org> wrote in message
news:Vkuea.68121$iq1....@nwrddc02.gnilink.net...
Deborah V. Gardner
with the inventory and customer contact side of it. Does this change any
opinions?
Deborah
P.S. The old 80/20 rule is always a good argument for just about any software.
Larry Linson
But, I respect Cary Prague's knowledge after reading books and articles he's
written, and, if you think you may need to change something... well, I don't
think you can modify QuickBooks.
But, if all you need to do is accounting, that may be the best solution.
"Deborah V. Gardner" <dgar...@twcny.rr.com> wrote in message
news:3E7A7B0E...@twcny.rr.com...
Ray
I am currently enabling my current client (using the export brokerage
package I developed for them in Access97) to post the results of their
particularly idiosyncratic business processes directly into the MYOB
database.
The MYOB add-on to achieve this is quite inexpensive. Quickbooks has similar
functions, but at Decision Time, there was no equivalent for the Australian
version. Simply Accounting let's you do a similar thing, but only for their
multi-user versions and providing you take out a mortgage on the house. I
don't know about any others - despite extensive research (and leaving aside
UA, YICRMB, and the other Access one whose name I can't remember, none of
which were Australianised, were too expensive, and/or left me doubtful about
their up-to-datedness), I couldn't find other packages that allow you to
send transactions directly into their databases.
One advantage of this hybrid approach, which if you are in the US would be
well worth considering with Quicken, is that the really CHEAP versions of
accounting software are designed for single user. The really EXPENSIVE
versions are multi-user. However, if you have a custom-made multi-user
MSAccess front end sending data to a single-user Accounting backend, then
you save OODLES. And some businesses find that they can hive off their
essential multi-user functions to an el cheapo MSAccess front-end and then
get away with a single-user accounting system at the back.
Whatever you might say about MYOB (and as far as I am concerned you could
say plenty), the end result for us has been simple and cost-effective. And
staying with mainstream accounting software allows you to keep right
up-to-date in the ever-changing and very wonderful world of beancounting.
Ray
Deborah V. Gardner <dgar...@twcny.rr.com> wrote in message
news:3E7A60F2...@twcny.rr.com...
Robert Crouser
applications in Access, could you clarify then why, if so much software is
available, were these applications done with Access? Or should they have
been? Or to put it another way, what is value of Access?
"Rick Brandt" <rvtjb...@sbcglobal.net> wrote in message
news:b5ds43$28mlu3$1...@ID-98015.news.dfncis.de...
(Pete Cresswell)
>So, to the posters here who have done
>applications in Access, could you clarify then why, if so much software is
>available, were these applications done with Access?
To me, there are really two questions:
1) To make or buy?
2) To use MS Access or something else to make?
The make-or-buy decision isn't always 100% rational. Sometimes managers just
want complete control over the app because of some gut feeling they have or
because they're not all that concerned with the amount of money the app will
cost.
Access vs, say VB or Visual Studio.NET has, to me, three components:
1) Maintainability by users: Maybe somebody wants an app that one of their
non-programmer technical people has at least a fighting chance of maintaining in
their spare time.
2) Calendar time to delivery. My experience is that, below a certain
size/complexity level, an app can be brought in via MS Access in much less
calendar time than by any other means. Once you get beyond a certain level,
however and team development takes over, all bets are off.
3) Money. I'd say that an MS Access app can be developed in 1/3 to 1/5 the
number of manhours that it would take using VB6. Haven't done any both ways in
Visual Studio.NET, so I can't comment on that.
-----------------------
PeteCresswell
David W. Fenton
<v7lmrg6...@corp.supernews.com>:
>I have run into the same question. So, to the posters here who
>have done applications in Access, could you clarify then why, if
>so much software is available, were these applications done with
>Access? Or should they have been? Or to put it another way, what
>is value of Access?
For cases where the off-the-shelf alternatives don't meet important
needs of the client.
For my philosophy on this, see:
When to Use Customized Software
http://www.bway.net/~dfassoc/custom.htm
Screenshots of an example of one such application can be viewed at:
http://www.bway.net/~dfassoc/Park/
Quickbooks could not handle that apps requirements because of the
need to store specific data about the customers' cars. It was
essential that this data be stored for communication with the
customers and with the garage attendants. But QuickBooks (and any
other commercial accounting package) makes no provision for storing
child records of a customer record. Indeed, there's no place for
information about even *one* car per customer. And they had very
specific needs for their invoices, which are a hybrid of an invoice
and a statement. Yet, they also treated the business as just barely
beyond a cash basis (this to my eternal frustration!).
So, they spent the money on developing a custom application to
handle their customer management and billing. That's precisely the
situation where it is justified. The people for whom that app was
developed manage 25-30 parking garages, and the marginal cost of
the development (it went live on the first test garage in July
1997, and fully live for all garages in January 1998; it's been in
use by 5 different users, each managing a subset of garages, since
then) was relatively low. The productivity costs of using an
application that doesn't do what you need would have been much
higher than the development costs of the custom application (which
was around $5-6K total).
Another advantage was multi-user capability, which QuickBooks (and
the alternatives) did not yet have in 1997.
So, there were plenty of good reasons for developing custom
software in that case.
And there are plenty of such reasons in all sorts of situations.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
David W. Fenton
<3e7a70ef...@news.westnet.com>:
>You my need to combine QB with one of their many add-on packages,
>or look at other systems.
Doesn't QB now support VB automation?
If all you needed was to supplement customer data storage, it might
be doable.
I, too, would hate to program an inventory system.
But I'd also hate to force clients to use QB to manage their
customer data!
Steven R. Zuch
Fenton) wrote:
>st...@nospam.com (Steven R. Zuch) wrote in
><3e7a70ef...@news.westnet.com>:
>
>>You my need to combine QB with one of their many add-on packages,
>>or look at other systems.
>
>Doesn't QB now support VB automation?
I think they have an API, but really have not investigated it. Any
time I interface with QB it has been to send JEs to QB, and I use
their input file format.
>
>If all you needed was to supplement customer data storage, it might
>be doable.
>
As I originally stated in my post, it really depends on the needs of
the client.
Having certain customer data stored in QB, and other in Access, may be
a solution; but there are issues about maintaining integrity between
the two system. If the customer database is relatively static in the
sense that they are not adding and deleting a lot of customers,
maintenance of such integrity may not be an overriding issue.
>I, too, would hate to program an inventory system.
>
>But I'd also hate to force clients to use QB to manage their
>customer data!
>
Me too, and clearly did not recommend it, and have not done it. We
have build seperate customer database systems, used for receivable
accounting and tracking demographic data, which interfaces with QB as
described above.
Steven
Robert Crouser
One realization that I am coming to is that as time goes on, the reasons are
less and less for using Access as functions are added to available programs
like QuickBooks. That means less work for Access developers (or no work at
all, eventually).
Anyone else have a must-use-Access situation?
"David W. Fenton" <dXXXf...@bway.net> wrote in message
news:934564433df...@24.168.128.74...
Richard Bernstein
news:934564433df...@24.168.128.74:
>
> So, they spent the money on developing a custom application to
> handle their customer management and billing. That's precisely the
> situation where it is justified. The people for whom that app was
> developed manage 25-30 parking garages, and the marginal cost of
> the development (it went live on the first test garage in July
> 1997, and fully live for all garages in January 1998; it's been in
> use by 5 different users, each managing a subset of garages, since
> then) was relatively low. The productivity costs of using an
> application that doesn't do what you need would have been much
> higher than the development costs of the custom application (which
> was around $5-6K total).
$6,000 is 100 hours (2 1/2 weeks) at $60/hr, maybe a fair guess at your
billing rate 5 to 6 years ago. The fee/time seems awfully low for the
functionality that the system appears to have.
Care to explain how you built that much functionality for such a seemingly
small fee, or so quickly?
Don't take this the wrong way, I am impressed. Many developers deliver
much less, in more time, for more money. The following is from another
message in this thread:
---------------------------------
"My experience is that for any reasonably-complicated "real-world"
application 200 manhours is about the bare minimum. That's a lot of bucks
compared to acouple hundred for QuickBooks. I'm (hopefully) in the home
stretch of a project/time management system that's up to 500 hours and will
certainly hit 650 before it's finally wrapped up."
PeteCresswell
---------------------------------
Richard Bernstein
(Pete Cresswell)
>Anyone else have a must-use-Access situation?
I've been through a number of must-make-own situations, but have yet to
encounter a clear must-use-Access situation.
"Clear" because some of the apps I do for the medical industry *may* be
must-use-Access situations because of the cost/benefit calculations involved. I
don't get to make that decision, however - all I do is talk to the users, write
the apps, and bill my hours.
-----------------------
PeteCresswell
Robert Crouser
don't-use-QuickBooks-or-any-other-off-the-shelf-software situations. That
was the subject of this thread, and a critical issue where computer
applications are concerned, and which I don't hear discussed often enough.
(But then maybe that's just me.)
"(Pete Cresswell)" <x@y.z> wrote in message
news:24bn7vk7lbf2ooctm...@4ax.com...
(Pete Cresswell)
>don't-use-QuickBooks-or-any-other-off-the-shelf-software situations. That
>was the subject of this thread, and a critical issue where computer
>applications are concerned, and which I don't hear discussed often enough.
>(But then maybe that's just me.)
1) A municipal bond trading system for one of the major mutual funds.
Everybody and their brother markets "bond trading systems", but nobody does muni
bonds. Other funds have tried force-fitting the muni desks to off-the-shelf
systems and it hasn't worked.
2) A timekeeping/project management system for a utility in a big city that's
been bought out by an even bigger utility. The IT managers keep getting calls
from above to expedite this or that project and in order to ask "which project
should be put on the back burner in order to expedite the other project?" they
need detailed information on who is participating in what project in certain
company-defined roles. They also want one-stop shopping for their employees:
somebody enters time into this thing, and it feeds PeopleSoft and the general
ledger system instead of the employee having to enter time three times.
3) A system to support a charitable endowment fund. Bill Gates wants to unload
a couple mil and take the tax break; but doesn't have the time or inclination to
dole it out to this charity and that charity. So he donates a the whole lump
to this fund. The fund invests it, and at any later date, distributes it in
accordance with Bill's wishes.
All three were done with Access front ends. #2 has a SQL Server back end.
#1 has been running for about six years and the desk it serves has been happy.
IT, OTOH, decided that they needed a single system to span several desks and
began a rewrite a little over a year ago. So far, they have five mil sunk into
it with an estimated 4 mil remaining. If you consider the entire nine mil, the
rewrite will cost about 24 times what I delivered the original for over an
evolutionary period of about four years. But that probably isn't fair since
most of the first five mil was wasted on some unfortunate blind ends and no code
was delivered. So, say five mil total instead of nine and the VB Studio.Net
rewrite is going to cost 12 times what the MS Access version cost.
#3 ran successfully for a couple of years, then IT took it over and rewrote it
as net-centric at (again...) approximately 12 times the cost that I billed on
the original system. They never did deliver a satisfactory product and in the
end the user went to a third vendor for another rewrite.
#2 is still in progress. The DB and all the screens seem to be in their final
state and a production rollout has been progressing for several months. A
number of reports, however, remain to be written. Although it's done with an
MS Access front end, what I've seen of VB Studio.NET makes me think that maybe
I'll choose this project to rewrite in .NET to compare manhours.
-----------------------
PeteCresswell
Bryant Farley
Synergration (http://www.coreobjx.com). You could ostensibly use Access (or
Prague's DB) for things QB isn't so friendly with, and QB for all the things
that it is so good at.
HTH
Bryant
--
Bryant Farley
Strategic Management Concepts, LLC
Web Design & Database Solutions
http://www.smc-llc.com
"Larry Linson" <larry....@ntpcug.org> wrote in message
news:uUwea.11683$IM3...@nwrddc03.gnilink.net...
Robert Crouser
http://www.bway.net/~dfassoc/custom.htm
Be sure to click on the green box about a third of the way down the
right-hand side of the page which will lead to some guidelines for deciding
to customize or not.
Robert Crouser
"David W. Fenton" <dXXXf...@bway.net> wrote in message
news:934564433df...@24.168.128.74...
Robert Crouser
I worked at 270 Park Avenue for years and later on Madison Avenue right near
there!
Robert Crouser
"David W. Fenton" <dXXXf...@bway.net> wrote in message
news:934564433df...@24.168.128.74...
David W. Fenton
<5dpo7vkest8mrgp20...@4ax.com>:
>#1 has been running for about six years and the desk it serves has
>been happy. IT, OTOH, decided that they needed a single system to
>span several desks and began a rewrite a little over a year ago.
>So far, they have five mil sunk into it with an estimated 4 mil
>remaining. If you consider the entire nine mil, the rewrite will
>cost about 24 times what I delivered the original for over an
>evolutionary period of about four years. But that probably isn't
>fair since most of the first five mil was wasted on some
>unfortunate blind ends and no code was delivered. So, say five
>mil total instead of nine and the VB Studio.Net rewrite is going
>to cost 12 times what the MS Access version cost.
>
>#3 ran successfully for a couple of years, then IT took it over
>and rewrote it as net-centric at (again...) approximately 12 times
>the cost that I billed on the original system. They never did
>deliver a satisfactory product and in the end the user went to a
>third vendor for another rewrite.
May I ask about what those people who wanted to discard your
working applications used as justification for doing so? This has
happened to me only once, and in that case even the developers of
the replacement system acknowledged to me that they couldn't quite
see what they'd been hired for as they were delivering an app with
less functionality than was already in place! In that case, it was
a management change combined with a desire to get away from
replication that caused them to make the decision. But what they
ended up with had even worse problems than replication and far
higher administrative costs.
But I wasn't even consulted to make a case for staying with the
existing app -- the management change put the people I'd worked
with on the project (for 3 years!) out of the loop on the
decision-making process.
The company hasn't gone under, but based on their website, it's
pretty clear that they've scaled back drasically, to about 1/4 the
size they once were. And the investment in the replacement system
happened in early 2000, just as the economy was tanking.
I'm surprised they are still in business!
But, anyway, I'd be interested in hearing the justifications for
replacing your systems, since I think such case studies can be
ammunition for those of us who encounter the same kind of dumb
initiatives.
David W. Fenton
<Xns93457565FBCDBri...@167.206.3.2>:
>dXXXf...@bway.net (David W. Fenton) wrote in
>news:934564433df...@24.168.128.74:
>
>>
>> So, they spent the money on developing a custom application to
>> handle their customer management and billing. That's precisely
>> the situation where it is justified. The people for whom that
>> app was developed manage 25-30 parking garages, and the marginal
>> cost of the development (it went live on the first test garage
>> in July 1997, and fully live for all garages in January 1998;
>> it's been in use by 5 different users, each managing a subset of
>> garages, since then) was relatively low. The productivity costs
>> of using an application that doesn't do what you need would have
>> been much higher than the development costs of the custom
>> application (which was around $5-6K total).
>
>$6,000 is 100 hours (2 1/2 weeks) at $60/hr, maybe a fair guess at
>your billing rate 5 to 6 years ago. The fee/time seems awfully
>low for the functionality that the system appears to have.
>
>Care to explain how you built that much functionality for such a
>seemingly small fee, or so quickly?
The original project was delivered on a fixed-price contract that I
purposely underbid, being in desparate need of work at the time. I
simultaneously underbid another project, too. So, my effective
rates on those projects were probably about 1/2 my hourly rate at
the time (which was $45 wholesale, $60 retail). My guess is that
the first $3K or basically represents about 100 hours, and the
remaining part another 50 hours or so.
I have recovered much of the losses on the original project in
support and enhancement work, as well as from selling the
application to other clients at $2K a pop. I do some adaptations
and provide 6 months of free support, but it's still a good deal
for me and for the new clients.
However, don't get me wrong: I'm not recommending such a strategy
unless you really do know that you're going to sell other copies.
In this case, I absolutely had no such plans. I underbid because I
was terrified of having any work. Indeed, just looking back at that
year, it was a big one, as I had those two projects going, as well
as picking up a huge project in August, and then starting initial
negotiations on another really major project in the Fall. I wasn't
completely finished with the original contracts on those two
underbid projects until January of the next year!
So, I learned my lesson there.
>Don't take this the wrong way, I am impressed. Many developers
>deliver much less, in more time, for more money. . . .
Well, nowadays *I* deliver less for more money, in some respects.
But I do think I deliver much, much *better* applications now, more
reliable, more user-friendly, with better data integrity and much
lower long-term maintenance costs. Yes, the initial costs are
lower, but the result is much better and much more easily expanded
and maintaine.
> . . . The following is
>from another message in this thread:
>
>---------------------------------
>"My experience is that for any reasonably-complicated "real-world"
>application 200 manhours is about the bare minimum. That's a lot
>of bucks compared to acouple hundred for QuickBooks. I'm
>(hopefully) in the home stretch of a project/time management
>system that's up to 500 hours and will certainly hit 650 before
>it's finally wrapped up."
I don't consider the Parking Garage app do be particularly
elaborate. The basic functionality was put together pretty quickly,
and then some of the things that you see in the final result were
added on later. What you see on the website is not the app that was
delivered in Summer 1997 for initial testing. Indeed, there was a
major rewrite of the way payments were handled in order to increase
performance. It wouldn't be a problem with today's PCs, but at the
time, the app was running on P100 computers with 40MBs of RAM!
That experience also taught me that writing even a simple billing
system can get enormously complicated. The app still doesn't handle
unapplied cash at all because it's so rare for this business and
because I never could figure out a simple way to do it with the
schema that I used. Had I planned for it, the schema would have
been quite different!
Of course, that's a caution for this thread: don't get into doing
accounting systems unless you *really* understand what's involved.
Having worked in Accounts Payable, I understand it from that end,
especially the problems that occur with the customers when
Receivables doesn't maintain sufficient information about payment
history or applies payments to invoices differently than the
customers want them applied. My app reflects that, but in terms of
handling Receivables, I didn't deal with quite a few important
things.
The idea of dealing with inventory frightens me greatly!
Given the situation of the original poster in this thread, I think
I'd be investigating exactly how much you can get out of QB by
automating it from Access. That might be the way to get exactly
what you need without having to rebuild the whole thing from
scratch.
David W. Fenton
>I worked at 270 Park Avenue for years and later on Madison Avenue
>right near there!
Park Avenue South and Park Avenue are not the same. Though it's the
same street (it would be Fourth Avenue if it followed the standard
numbering) the numbers for Park Avenue start over at 30th Street.
David W. Fenton
>On Fri, 21 Mar 2003 14:30:02 GMT, dXXXf...@bway.net (David W.
>Fenton) wrote:
>
>>st...@nospam.com (Steven R. Zuch) wrote in
>><3e7a70ef...@news.westnet.com>:
>>
>>>You my need to combine QB with one of their many add-on
>>>packages, or look at other systems.
>>
>>Doesn't QB now support VB automation?
>
>I think they have an API, but really have not investigated it.
>Any time I interface with QB it has been to send JEs to QB, and I
>use their input file format.
I've used it, too, but it's pretty dreadful, in my opinion!
>>If all you needed was to supplement customer data storage, it
>>might be doable.
>
>As I originally stated in my post, it really depends on the needs
>of the client.
Agreed, naturally.
>Having certain customer data stored in QB, and other in Access,
>may be a solution; but there are issues about maintaining
>integrity between the two system. If the customer database is
>relatively static in the sense that they are not adding and
>deleting a lot of customers, maintenance of such integrity may not
>be an overriding issue.
Well, in terms of customers, if the entire customer data structure
can be manipulated through automation, you could have a policy of
doing all updates/additions from Access, and this would mean you'd
always be dealing with current data.
But, again, I haven't looked at it.
I am not as keen on this kind of thing as I once was (as reflected
in the documents on my website, which date back to as far as 1996).
>>I, too, would hate to program an inventory system.
>>
>>But I'd also hate to force clients to use QB to manage their
>>customer data!
>>
>
>Me too, and clearly did not recommend it, and have not done it.
>We have build seperate customer database systems, used for
>receivable accounting and tracking demographic data, which
>interfaces with QB as described above.
The problem with that, though, is that you have to have the
customer data and the receivables data, and when I tried doing this
(several years ago, granted), there was no decent way for keeping
the child records coordinated with the parent records because QB's
internal structures were not available.
Basically, I've never done anything beyond loading initial customer
data and then exporting journal entries (aggregate account changes
for a period from Access; actually, a bit more complex than that,
but not by much).
Robert Crouser
Oh. I'm away from New York for two years and I forget already. I guess
you're in the Gramercy Park (my dentist was there) or new York Life
Insurance area.
Robert
(Pete Cresswell)
>
>But, anyway, I'd be interested in hearing the justifications for
>replacing your systems, since I think such case studies can be
The charitable endowment app was to have a C/S back end, but the client came up
with such an aggressive deadline that I said "Ok, I can make that deadline if we
do it with a JET backend. I'll code as if C/S and we'll convert later."
Of course "later" never came. Eventually they wound up with some sort of LAN
problem and the back end started corrupting every hour or less. It's a huge
company with a very tightly-controlled environment so we couldn't just move it
to another server. The client went though absolute Hell for over a month while
all the king's horses and all the king's men tried to put it all together again
- but nobody would. Sniffers, protocol experts...whatever expertise a
10,000-employee company who is heavily into DP can come up with all took their
best shot.
Finally, after all that they let us move it to another server and the problem
disappeared instantly, never to return.
That experience, however, was so awful for the client that they asked IT to bail
them out. IT said "sure, but we do it OUR way...".... and debacle #2 began
with IT racking up close to a mil on the project and the user never being
satisfied.
The bond trading app is still running today. The trading desk that uses it is
still happy and never wanted anything else. Upper management, however, looked
at some of the other desks' "systems" and got nervous....especially after the
Enron thing. They wanted one system across many desks that would let the
upper-upper-upper management assess exposure at any time.
The app, as written, was not up to covering three or four trading desks (say 10
traders per desk...with different requirments for different desks)...plus it was
another one of those "JET today, but C/S Sometime Soon..." situations. Never
again for Yours Truly....
By then the company had purged most contractors, so my expanding the existing
app and converting it to C/S wasn't in the cards.
Actually, I'm still getting a minor gig out of the rewrite project because I add
some value as the resident expert in the app they are cloning and somebody
somewhere relaxed the ban on contractors enough for them to retain me for a few
months.
And, in truth, watching this 5 mil project up close; I realize that it's way,
*way*, WAY over my bald little head. I've definately got my place: I deliver
stuff that works and I deliver it faster and cheaper than any IT org can...but
with the level of complexity, analysis, and teamwork that I see in this project
sometimes I feel like a real bozo - until I remind myself that the cost factor
is close to 1:12....
I still think I could have delivered the same functionality given, say, two or
three years and the ability to work my way in my environment - but these guys
don't *have* two or three years and besides it probably would have taken ten off
my life.
The lesson I take away from these two and some other projects is that JET is not
the right choice for a mission-critical back end. It can run flawlessly for
five, six years - true. But there's a sort of sword of damoclese (sp?) hanging
over a JET back end and "if you can't afford to lose, don't play the game"...
On succeeding mission-critical projects, I have argued for a SQL-Server back end
and prevailed. I still do JET back ends for my medical industry projects, but
they're very small administrative/data conversion things.
Maybe I've been working too many hours and it's warped my mind but right now I
think I'd turn down a project which was clearly mission-critical but for which
the user wanted a JET back end.
-----------------------
PeteCresswell
David W. Fenton
>RE/
>>
>>But, anyway, I'd be interested in hearing the justifications for
>>replacing your systems, since I think such case studies can be
>>ammunition for those of us who encounter...
>
>The charitable endowment app was to have a C/S back end, but the
>client came up with such an aggressive deadline that I said "Ok, I
>can make that deadline if we do it with a JET backend. I'll code
>as if C/S and we'll convert later."
>
>Of course "later" never came. Eventually they wound up with some
>sort of LAN problem and the back end started corrupting every hour
>or less. It's a huge company with a very tightly-controlled
>environment so we couldn't just move it to another server. The
>client went though absolute Hell for over a month while all the
>king's horses and all the king's men tried to put it all together
>again - but nobody would. Sniffers, protocol experts...whatever
>expertise a 10,000-employee company who is heavily into DP can
>come up with all took their best shot.
>
>Finally, after all that they let us move it to another server and
>the problem disappeared instantly, never to return.
>
>That experience, however, was so awful for the client that they
>asked IT to bail them out. IT said "sure, but we do it OUR
>way...".... and debacle #2 began with IT racking up close to a mil
>on the project and the user never being satisfied.
I assume that moving the back end to a different server was the
first thing you suggested?
And they didn't do it, and they went through a month of problems.
And when they did do it, the problems immediately vanished.
But that didn't give you any credibility, of course.
Arrgh.
In any event, your story does show, I think, that it's important
not to obsess on hardware issues. My bet is that the server that
caused the problems had not been altered hardware-wise, but that
some kind of software patch of some kind had been installed on it.
That's one thing that I definitely believe is under-rated as a
cause of Access corruption -- completely unrelated software patches
on servers. I've seen it once and it was one too many times.
The truly frustrating thing about the situation where I encountered
corruption caused by a hotfix installed on the server was that the
software it was applied to (Exchange Server) was not even being
used by the client!
I know an Access contractor who is writing some kind of bond
trading app for a client. He and his partner come to *me* for
advice on SQL Server (i.e., they know less about it than *I* do!),
and the project has a budget of something like $250K.
I could *never* take on a project of that magnitude when I didn't
have the expertise to deliver it.
If I *did* have the expertise, I could definitely manage a team, if
required. But I'd need to be able to have the authority to hire the
people for the project, as I only trust the people I already have
faith in.
>The lesson I take away from these two and some other projects is
>that JET is not the right choice for a mission-critical back end.
> It can run flawlessly for five, six years - true. But there's a
>sort of sword of damoclese (sp?) hanging over a JET back end and
>"if you can't afford to lose, don't play the game"...
Well, it all depends on how "mission critical" is defined. All my
clients consider their apps "mission critical" because they
couldn't run their businesses without them. But 100% of them are
Jet back ends. While it would be bad for them to have downtime or
to lose any significant amount of data, the cost of that downtime
and data loss does not balance for them against the administrative
costs of SQL Server. Most of the apps I've created in the last 3 or
4 years for user populations over 10 or so have incorporated as
much C/S-ready principles as I could get into them, on the
possibility that it would be upsized.
But I haven't yet convinced any of my clients that they need to
upsize, either in terms of stability or performance, because all
the apps have been stable (no data loss, virtually no downtime) and
have been perfectly satisfactory in terms of performance.
Jet amazes me, to be honest.
>On succeeding mission-critical projects, I have argued for a
>SQL-Server back end and prevailed. I still do JET back ends for
>my medical industry projects, but they're very small
>administrative/data conversion things.
The kinds of projects you've described definitely ought to be C/S,
I think. But those are very different from the kinds of apps I've
done, where Jet has been more than adequate.
>Maybe I've been working too many hours and it's warped my mind but
>right now I think I'd turn down a project which was clearly
>mission-critical but for which the user wanted a JET back end.
Wouldn't it depend on the application? I mean, do you really think
a contact management app for 15 users really needs to be C/S? I
certainly don't.
David W. Fenton
>"David W. Fenton" <dXXXf...@bway.net> wrote in message
>news:9346BB479df...@24.168.128.74...
>> robert....@gte.net (Robert Crouser) wrote in
>> <v7pmp19...@corp.supernews.com>:
>>
>> >I worked at 270 Park Avenue for years and later on Madison
>> >Avenue right near there!
>>
>> Park Avenue South and Park Avenue are not the same. Though it's
>> the same street (it would be Fourth Avenue if it followed the
>> standard numbering) the numbers for Park Avenue start over at
>> 30th Street.
>
>Oh. I'm away from New York for two years and I forget already. I
>guess you're in the Gramercy Park (my dentist was there) or new
>York Life Insurance area.
Well, I'm not there now. High rents forced me to move to Astoria in
Nov. 2000. I now have a very nice 1 bedroom apartment for $14/month
more than what I would have been paying to continue sharing the 1BR
on Park Ave. South.
I need to update my web page, obviously.
Robert Crouser
You don't say if you're renting or buying but if you are renting for $14 a
month more than before, buy yourself a place. I regret (unfortunately) the
fortune I threw away on my apartment in my New York years.