Data Location on the Optimal Platform
You get maximum performance when you store data and other attributes of your database on the optimal platform. The best platform for a particular element depends on how the element is accessed and updated. For example, you might want to store a local copy of a server table, such as a postal code directory that is used as a lookup table, and refresh the local copy only when the back-end table changes.
The following table lists some common application elements and examples of where to locate them for optimal performance.
Locating Elements by Platform
Element |
Location |
Type |
Notes |
|---|---|---|---|
Tables |
Local |
Local copies of server lookup tables; small, infrequently changed tables |
Use a time stamp, if supported by your remote server, to compare and optionally refresh the local table to match any changes to the back-end source table. |
|
Remote |
Large or frequently changing tables |
|
Rules |
Local |
Rules on remote views |
You can use DBSETPROP( ) to store field- and record-level rules on a remote view. Your application can use these local rules to check the validity of data before sending the data to the back-end as an update to remote tables. |
|
Remote |
Row-level and column-level rules on remote base tables |
|
Stored procedures |
Local |
Visual FoxPro stored procedures |
|
|
Remote |
Stored procedures on a remote server |
Use the SQL pass-through SQLEXEC( ) function to call stored procedures on a remote server. |
Transactions |
Local |
Visual FoxPro transactions |
|
|
Remote |
Server transactions |
|
Triggers |
Local views |
No triggers on views |
|
|
Remote |
Server triggers |
|
To reduce network traffic during lookups, you can choose to store not only infrequently changing but also frequently changing lookup tables locally. For example, you can download your company's customer list and refresh it only when customer information changes.
To accomplish this, you can program your application to compare the time stamp on the local copy of the table with the time stamp on back-end data (if your remote server supports time stamps) and update the local copy only if the server table has changed. You can also add a command button to your form that forces an immediate download of the table, allowing users to refresh their copy of the local table on demand.
See Also
Concepts
Performance Enhancement through Set-Based Data Access
Client/Server Design for High Performance
Other Resources
Planning Client/Server Applications