Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

-General database discussion FAQ

DB Debugging & troubleshooting

0. Introduction by jrbarnett
Posted: 14 Apr 14 (Edited 18 Apr 14)

Many organisations have had applications developed by non professional developers without the foresight to properly document their applications (if at all); over time the applications grow and change beyond their original minimal remit, sometimes to the stage of becoming critical to the operation of an organisation in all or part. It gets even more difficult if the original developer leaves and other people need to maintain their work without having the time to redevelop it from scratch properly.
The tools, tips and tricks can also be useful if it is a commercial system but the supplier goes out of business or de supports the system and refuses to provide alternative cover.

This guide goes through the steps needed to understand an application and document it properly. In essence, it is simply the application to computer software of evidence based principles as used in scientific research. It is not a quick process at all, but the effort in doing this will reap rewards in terms of understanding your application and easing future maintenance and new development work. Not all examples will apply to all pieces of software or development platforms, so apply common sense to your own investigations.

I have written this without reference to specific technologies or platforms, so instructions for using them will not appear, but product names as examples of what I mean may show up from time to time.

This is designed as a high level set of steps to follow, with some details on what to do at that stage. It is split into separate sections, but they are not to be read and executed in a linear order - this is a highly iterative process.

As you progress through and get a greater understanding of aspects of your application, document it and put it somewhere obvious.
Don't let other people have to repeat your work in the future. Don't make any changes to the code until you have seen an application itself from end to end as changes may have unforeseen consequences.
Equally, if you find bugs or get issues reported to you while doing this process, just log them in the corporate standard issue tracking software. Don't attempt to remedy the situation until you are comfortable with the application from end to end.

The aim of this set of FAQs is that by doing this, you can get to a stage where:
i) the application is understood enough that it can be supported until such a time that it can be retired or replaced
ii) the application is good enough to meet corporate requirements for a supported system.

Good luck

Next section: FAQ669-7710: 1. Get an overview of the application from an end user's perspective

Back to -General database discussion FAQ Index
Back to -General database discussion Forum

My Archive

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close