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
11  2639 
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.
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
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
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
"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
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
"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/
"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/
"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/
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/
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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: bettina |
last post by:
I have the following piece of code (symplified)
require("lang.{$lang}.inc.php"); // I include the inc. files
....
function decodify($technique) { // functions that give me back the
value in...
|
by: Mario Horvat |
last post by:
i'm writing small app in Access 2003 VB and it looks like somehow error
traping does not work anymore.
When i start the form and do some actions (with vb code behind it), if it
comes to a place...
|
by: Richard Cleaveland |
last post by:
I have been comfortable debugging VBA modules using Access 97. I recently
acquired Office XP and converted my applications to Access 2000. In general
they seem to run fine, but there's a bug in...
|
by: freegnu |
last post by:
how to declare a friend function that can access two class
it will look like the following
class A
{
private:
int i;
public:
A(){}
~A(){}
friend void call(A &a, B &b);
|
by: bhavin30 |
last post by:
Is there a way to obtain user information (using LOGON_USER server
variables) when you have set up the security to Anonymous Access? I
have tried setting the security to both Anonymous + Window...
|
by: jthep |
last post by:
I'm trying to get this piece of code I converted from C to work in C++ but I'm getting an access violation error. Problem occurs at line 61. Someone can help me with this?
The function...
|
by: Sh4wn |
last post by:
Hi,
first, python is one of my fav languages, and i'll definitely keep
developing with it. But, there's 1 one thing what I -really- miss:
data hiding. I know member vars are private when you...
|
by: Stephen Horne |
last post by:
I've been using Visual C++ 2003 for some time, and recently started
working on making my code compile in GCC and MinGW. I hit on lots of
unexpected problems which boil down to the same template...
|
by: sva0008 |
last post by:
i have a auto suggest script that does not work in firefox , works great on IE.
/*******************************************************
AutoSuggest - a javascript automatic text input...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
