home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware 1 2 the Maxx
/
sw_1.zip
/
sw_1
/
TEXT
/
PDX_ALL.ZIP
/
TI544.ASC
< prev
next >
Wrap
Text File
|
1991-09-11
|
3KB
|
67 lines
PRODUCT : PARADOX NUMBER : 544
VERSION : 3.x
OS : DOS
DATE : September 11, 1991 PAGE : 1/1
TITLE : USING QUERYSPEEDUP TO IMPROVE APPLICATION
PERFORMANCE IN PERSONAL PROGRAMMER
The QuerySpeedup option (see page 191 of the Paradox User's
Guide) creates a secondary index or "key field" designation to
improve search and sort times when processing data in a large
table which already contains a primary key field. In Personal
Programmer, operations involving the SelectRecords or Sort
functions can be significantly accelerated.
Establishing a secondary index (using QuerySpeedup) is quite
easy. Simply view the table you wish to accelerate query options
on (you may have to change the working directory to PPROG or
wherever the application is stored) and select
Tools/QuerySpeedup. This will create a file with the same
filename as the table but with a .X00 or .Y00 extension. The
message "QuerySpeedup Recorded" will appear at the bottom of your
screen. Once created, however, the index must be maintained to
continue to accelerate processing time.
If the table in question is "keyed" (i.e., contains a primary
index field indicated by an asterisk next to the field type in
the table structure), then the option "MaintainIndexes" in the
Custom Configuration Program (page 265 of the User's Guide) must
be set to YES. This allows Personal Programmer (and Paradox) to
incrementally update the secondary index every time a change is
made to the table. Once this selection has been made and the
changes saved, a new PARADOX3.CFG will be created. In order for
these changes to have an effect in Personal Programmer, the
PARADOX3.CFG file needs to be copied into the PPROG subdirectory
and renamed PPROG.CFG (using the DOS copy and rename commands,
respectively).
If the original table is not keyed, however, the secondary index
will not be recognized or maintained until a query
(SelectRecords) is generated. This may actually have a negative
effect on processing speed when the query is generated because
the application has to first update the secondary index and then
process the operation. (Note, if the same query is run a second
time before any changes have been made to the table, performance
will be improved -- but only until the next time the table is
changed in any way). Therefore, the use of QuerySpeedup on non-
keyed tables is not recommended unless a number of queries are
going to be used and no changes are made to the table between
queries.