By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,687 Members | 2,055 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,687 IT Pros & Developers. It's quick & easy.

Does Access Break?

P: n/a
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
May 4 '07 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Earl Anderson wrote:
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

Back up the database once in a while.
May 4 '07 #2

P: n/a
a lot of things could *potentially* happen to "break" the code in an Access
application; it depends in part on what's written into the code and how it's
written. as for fixing somebody else's application - that mainly depends on
whether the application was written substantially above the skill level of
the person trying to troubleshoot it, and how good that person is in
researching problems that s/he may not be familiar with.

hth
"Earl Anderson" <is*****@optonline.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


May 4 '07 #3

P: n/a
Earl Anderson wrote:
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"?
Computer programs are logic instructions. If a program works today it
should work tomorrow. If the program has syntax errors or logic errors
the same error will occur and you should not expect different results.

But you could have a network card/cable malfunction. Or perhaps a
service patch difference between computers. Or perhaps by uninstalling
something a reference that is needed is broken.

I should think that in 2 years of use that you would have discovered
problems by now.

In your case, what you have is what you will have. It doesn't sound
like you have had any need to enhance or modify the program. In the
future, you may need to make adjustments. I would consider what you
might need in the future.

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?
Any Access programmer worth his salt could read the programmers code and
enhance or modify it. Now why a programmer did something is another
matter. Let's say the code is
If Status = "A" then
Extended = Cost * Qty
Else
Extended = Cost * 2
Endif
OK, so if the status is A then multiply the cost times qty otherwise
multipley the cost by 2. Why is that? In this case you'd need to ask a
user why this occurs. Hopefully there is a user around that
understands the reasoning behind it if the programmer did not document
it. Not all code is documented in this world.

In your situation your company was aquired by another. And it is
supported by their IT department. You might be banging against a brick
wall on this matter and may be better off grinning and bearing it and
yearning back to the days of old but stuck in the present.
Thx...
Earl Anderson

May 4 '07 #4

P: n/a
On Thu, 3 May 2007 21:37:39 -0400, "Earl Anderson"
<is*****@optonline.netwrote:

It seems you are intent on getting arguments to defend "your"
application because it is superior to others IYHO.

The decision to use or discontinue use of certain applications should
probably be taken at a higher level in the organization, and not be
(too much) influenced by turf wars. You can contribute to that.

To answer your questions: no, no.

-Tom.
>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
May 4 '07 #5

P: n/a

"Earl Anderson" <is*****@optonline.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
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.

And, how easy it is for another person to read, understand, and modify the
application will depend on several factors. The first stumbling block would
be if all you have is the "compiled" (MDE) version, though the file
extension might have been changed. In an MDE, the code is processed and
locked, so you can't view it in design view. Developers keep an MDB copy
for their development work, and create a new MDE each time they distribute
to the users.

Good "insurance" to reduce the possiblity of it 'breaking' is to split the
front-end (queries, forms, reports, macros, and modules) from the back-end
(tables, relationships, and data). Each user gets their own copy of the
front-end, and the back-end is put in a shared folder (to be shared). You
link the tables from the front end to the back end.

If no one in your user department is knowledgeable about Access and no one
in the IT department is interested, then you need to invest in some
self-study books, check out training available online (there are free
on-line courses available via http://office.microsoft.com that will help you
get started), or get your management to sponsor attendance at a
stand-up/in-person class. Alternatively, you could locate someone who does
Access work on contract to do what you want; and, perhaps it would be a good
thing to contract someone just to examine the database and help you
understand what your options are.

In general, I believe that for those database applications suitable for
Access (single-user, multi-user split Access-Jet, or client-server with
Access client and a server DB), there is no better tool for ease and speed
of development, and solid, usable applications. Assuming you have the
"maintainable" version, there is also, in my opinion, no development tool
that creates easier-to-maintain applications.

But there are tools who have vocal advocates, and sometimes those vocal
advocates will tell you "how inadequate Access is" (as though they actually
knew, which most of them don't) in order to sell their own development
project. And, due to lack of knowledge (apparently already admitted by your
IT department, or observed there by you), many IT departments are offenders
in this area, too; they often have "pet contractors" to whom they will refer
you to get a "real database application".

Larry Linson
Microsoft Access MVP
May 4 '07 #6

P: n/a
Hello Earl,

I do this all the time! I specialize in adding new functionality to existing
databases, making modifications to existing databases and fixing problems in
existing databases.

PC Datasheet
Providing Customers A Resource For Help With Access, Excel And Word
Applications
re******@pcdatasheet.com


"Earl Anderson" <is*****@optonline.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

May 4 '07 #7

P: n/a
"Earl Anderson" <is*****@optonline.netwrote in
news:H7**************@newsfe12.lga:
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"?
No. On the contrary, I see lots of apps that were held together with
chewing gum and baling wire that have been in operation without any
problems at all for years and years. The only time I see these apps
is when the scope grows and new features are needed. I do my best to
leave the old stuff alone (though it pains me to do so!) insofar as
it's possible for me to do my job without changing the existing app.
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?
The difficulty a new developer will have in working with an existing
app will depend on:

1. how good the skills of the new developer are and how experienced
she is with the problem space involved.

2. how well-designed and documented the existing app was.
Documentation may be nothing more than a few judicious comments and
well-chosen names for code subroutines and Access objects.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
May 4 '07 #8

P: n/a
"tina" <no****@address.comwrote in
news:o3********************@bgtnsc04-news.ops.worldnet.att.net:
a lot of things could *potentially* happen to "break" the code in
an Access application; it depends in part on what's written into
the code and how it's written.
Please list some. I don't know of anything that would be a part of
daily use that would cause an app to break if nobody was mucking
around with editing the application's objects/code.

That is, if you don't change forms or queries or code, it's just not
going to break spontaneously.

The only exception to that would be data-based issues, such as
reaching a point where you need to store an incremented number in,
say, an integer field when the next value needs to exceed the scope
of the integer data type. Some of those kinds of things are actually
relatively easy to catch, while others can be devilishly difficult.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
May 4 '07 #9

P: n/a
"Larry Linson" <bo*****@localhost.notwrote in
news:2Ky_h.28498$IJ3.27271@trnddc07:
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/
May 4 '07 #10

P: n/a
I agree that it isn't necessarily "permanently 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*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
"Larry Linson" <bo*****@localhost.notwrote in
news:2Ky_h.28498$IJ3.27271@trnddc07:
>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/

May 5 '07 #11

P: n/a
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*****@optonline.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

May 8 '07 #12

This discussion thread is closed

Replies have been disabled for this discussion.