Kbase 300: When Query Forms don't compile: Common causes
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
When Query Forms don't compile: Common causes
910719-elp20
2. When Query Forms Don't Compile:
2.1. The .ql Query Log File
In V5 RESULTS, you must know enough to look in the .ql file for any
query form compile errors. RESULTS simply hides the failed forms
from the scrolling list.
In V6 RESULTS, we give you an on-screen listing of any query form
compile failures, marking the compile errors in reverse video. This
happens both at Initial Build and Application Rebuild.
The .ql is created during Initial Build. All compiles of query forms
are appended to this file, during both Application Rebuild and Form
Definitions for Query.
2.2. Some Common Causes of Compile Failures
2.2.1. 100-field limit
If you have more than 100 fields in your database with the same name,
PROGRESS will fail to compile a program if it does not fully qualify
the field name with the file name. This can also occur if more than
100 fields begin with the same name as another field (for example,
cust and cust-num, cust-name, cust-date).
V5 work-around: manually edit the query form program (.p, .i and .f)
to qualify the field names with the file names.
V6 work-around: not needed. V6 automatically qualifies names where
necessary.
2.2.2. Missing Validation Files
One common problem is that .v validation files, as referenced in the
dictionary, are not available (not in the PROPATH) when RESULTS is
building.
Solution: Fix the PROPATH.
2.2.3. Shared Variable in Validation Expression
Another more difficult problem is when the validation expression
references a shared variable. Since there is no easy way to place
the "DEFINE SHARED VARIABLE" declaration into the query procedure,
these type of validation expressions are doomed to failure.
Solution #1: hack the query form .p by hand. Note that an
Application Rebuild may undo this fix.
Solution #2: change the validation expression.
2.2.4. R-code Greater Than 63K
This can happen for many reasons:
- PROGRESS makes r-code big if there are a lot of fields in a
file. Whether those fields are actually referenced is
irrelevant.
- Big validation expressions.
- Long help messages and/or validation messages.
- In V6 decimal items with Query enabled expand to a complicated
expression to support "." or "," as the decimal character.
- Complicated forms and/or long labels.
- Long formats.
How can you shrink the r-code?
- Eliminate all Browse fields. (Say "no" to the "Brow?" column in
"Admin->Form Definitions->Which Fields").
- Eliminate all Add/Update/Copy fields. (Say "no" to the "Upd?"
column in "Admin->Form Definitions->Which Fields").
- Eliminate all Query fields, and use the Where option instead.
(Say "no" to the "Qry?" column in "Admin->Form Definitions->Which
Fields").
- Consider using one form for Query and a different one for
Add/Update/Copy.
For the sample customer file in the demo database, here are some
examples:
38,296 - standard customer.r
36,836 - with no browse fields
35,220 - with no update fields
22,250 - with no query fields
17,544 - with no browse/update/query fields
All of the above guidelines apply both to V5 and V6 RESULTS, although
the numbers about came from a V6 test.
Progress Software Technical Support Note # 300