Kbase 20970: ADM2. Things to Know When Investigating ADM2 Problems
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
16/10/2008 |
|
Status: Unverified
GOAL:
ADM2. Some time saving techniques TIPS to employ when you investigate problems in an ADM2 application before contacting Tech Support.
FACT(s) (Environment):
Progress 9.x
CAUSE:
Often there are key elements missing from reports of problems that come to Progress Technical Support that could potentially save a great deal of time, and even mean the difference between whether or not an issue ever gets resolved.
FIX:
In the case of the Application Development Model, there are some basic things to keep in mind that, like as not, help to diagnose what the problem is.
Consequently, the following tips are as much a "best practices" white paper as they are a "how to triage" document. The tips are as follows:
Always, always, always check your patch level and make sure that you have recompiled your application since you applied the patch.
This is the very first direction you should look. Good source code control is the most important part of writing any application, and it is even more important with the ADM.
One example of a problem that could occur is:
Error 5639 - User-defined function '<function>' invoked dynamically but could not be found.'
In essence, this error means that you have tried to execute a function call in a procedure where that function has not been defined.
Quite frequently, this error is returned in Progress ADM2 applications after a patch is applied. This is usually because a function has been added to, or removed from, the ADM support code, or a function call has been moved and the application has not been recompiled to take the move into account.
After you check your patch level and ensure that you have compiled your application against the applied patch, and you are absolutely certain that you are running the r-code you think you're running...
Check the latest patch page to see if one of the descriptions of one of the fixes for the current patch level matches, or looks like, your issue.
As long as you are not in a production environment (for example, a development environment), you should in general keep up with the latest patch level on a fairly regular basis.
If you are in a production environment, it is better to be safe not sorry. Check with Progress Technical Support to verify whether or not the issue that is reported in the patch is the same as the one that you are seeing.
Once you have verified that the issue has not been addressed in a patch, you should verify that you have no in-process overrides that could be manipulating the property settings in the ADM.
An example of an 'in-process' override is calling refreshRow from postTransactionValidate. This is a big No-No and here's why:
While this might seem to be an appropriate place to do an override because the transaction is technically over, the commit process that is used is very complex and not only manipulates data, but it manipulates the UI.
The process requires free reign to navigate the query in order to set properties that the UI subsequently uses. If you call something like refreshRow in the middle of that process, you potentially could be telling the query to do one thing while the properties are telling the UI to do something entirely different.
At best, this could cause your query and interface to be out of synch, cause errors to display or, even worse, possibly cause data corruption.
The appropriate place to call refreshRow after a transaction is 'AFTER the transaction'. For example, after SUPER in an override of commitTransaction.
Always take into account any custom code you might have applied.
Please remember that the ADM cannot do everything and, the very idea of it encourages code customization and the creation of your own custom classes.
If an error is happening and you are not sure where it's coming from, a good alternative is to go right into the debugger and blindly step through tons of ADM code by starting your session with the -debugalert parameter.
With this parameter, any errors that are displayed include a Help button on the message box. When pressed, the button displays a dialog with a stack trace of the last routines called.
Look in the stack trace too see if it contains calls to your own applicati.on's routines rather than just ADM2 calls.
This is key in your assist of Progress Technical Support to help you get to the bottom of the problem. This is not to say that just because custom code is involved in causing a problem that the code is inappropriate..