Does Access Break?

[Earl Anderson]

Our company has been acquired by another company and we are going thru the
integration process. One of the "Day 1" items is settling on a departmental
database used to track departmental functions. A former employee built our
Access application, however he is now long gone. During the 2 years he's
been gone, the application has worked just fine with no problems. The new
acquiring company's department has a like application (not sure if Access or
some other db format) with much less functionality, however they want to
keep their own and not use ours, citing that theirs is supported by their IT
Department while ours is not and since the developer is no longer with our
company, there is no one who could repair it should something happen to it.
(Although MS Office Pro is a company standard, our company has no one in IT
that is fluent in VBA).

Two (2) questions please. First, has it been your experience as developers
that once you build something in Access and it has been tested and used
extensively by the client over a period of years that you are called back to
fix something that "broke"? Second, if something did "break" in the
programming, is it extremely difficult to read another developer's
programming to determine what he did and how he did it, so that a problem
could be diagnosed and repaired by a new and different developer/programmer?

Thx...
Earl Anderson

[Larry Linson]

I agree that it isn't necessarily "permanentl y broken", but was considering
"something happening that caused the application not to work" as "breaking".

Certainly, at the extreme, corruption can be such that it isn't repairable.
And that could happen on the Front End code, too. If there was no usable
backup or previous version, it would be "non-trivial".

I suppose "one of the vital rules to follow" is still "back up your database
on an appropriate schedule". If the front-end is the one corrupted, it can
just be replaced with the working copy that was used to create the
distributable -- if the app is split. If it's the back-end, and no one can
figure a quick-fix to identify and correct the problem, then the latrest
backup copy and transaction log will be what's needed.

Larry
"David W. Fenton" <XX*******@dfen ton.com.invalid wrote in message
news:Xn******** *************** ***********@127 .0.0.1...

"Larry Linson" <bo*****@localh ost.notwrote in
news:2Ky_h.2849 8$IJ3.27271@trn ddc07:

>Yes, things can happen that 'break' an application, but the good
thing is, if the database is reasonably well-done, using the
Compact and Repair function will usually fix it.

Larry, you're using a completely different definition of "break an
application" than I interpreted as being intended. Corruption is not
really what I'd consider "breaking an application" -- when the phone
line is down you don't blame the fax machine for being unable to
send a fax, so I consider corruption issues to be failures *outside*
the application's logic, and not really a breakdown of the app
itself -- it's a breakdown of the operating environment.

If the code in an app works and remains unaltered, there are very
few things that can happen that can break it, and the longer the
code has been in use the more this is the case.

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

[Steve]

Even a well designed, normalized database can have performance issues as the
database grows. Applications which handle 100,000 transactions well, may
crawl in certain circumstances with 1 million transactions. Access in a
multi-user system can be subject to this problem, since certain queries may
require sending the full tables to the client.

If the system is very transactional, and does not have the ability to
"purge" data, this could be a problem.

Steve
"Earl Anderson" <is*****@optonl ine.netwrote in message
news:H7******** ******@newsfe12 .lga...

Our company has been acquired by another company and we are going thru the
integration process. One of the "Day 1" items is settling on a
departmental database used to track departmental functions. A former
employee built our Access application, however he is now long gone.
During the 2 years he's been gone, the application has worked just fine
with no problems. The new acquiring company's department has a like
application (not sure if Access or some other db format) with much less
functionality, however they want to keep their own and not use ours,
citing that theirs is supported by their IT Department while ours is not
and since the developer is no longer with our company, there is no one who
could repair it should something happen to it. (Although MS Office Pro is
a company standard, our company has no one in IT that is fluent in VBA).

Two (2) questions please. First, has it been your experience as
developers that once you build something in Access and it has been tested
and used extensively by the client over a period of years that you are
called back to fix something that "broke"? Second, if something did
"break" in the programming, is it extremely difficult to read another
developer's programming to determine what he did and how he did it, so
that a problem could be diagnosed and repaired by a new and different
developer/programmer?

Thx...
Earl Anderson