When you specify field lists, the AVM is very flexible where it cannot make use of them. The AVM either returns complete records automatically or allows you to bypass field list processing completely for the following cases:
DataServers that do not support SHARE–LOCK — If you execute a SHARE–LOCK fetch from a DataServer that does not support SHARE–LOCK, the AVM ignores the field list and retrieves the complete record. In some circumstances, the AVM must replace the fetched record with a new version. Because the SHARE–LOCK is meaningless, the new version can be different from the previous one, and the AVM requires the complete record to ensure that the user receives the correct data.
Note: You can avoid SHARE–LOCK fetches with the help of the CURRENT–CHANGED function. For more information, see OpenEdge Getting Started: ABL Essentials.
Multiple queries returning the same record — If you specify two queries that return two different field lists for the same record, the AVM cannot always consolidate the two lists. In that case, the AVM must reread the complete record. Such occurrences are rare, but they can impose a minor performance penalty with little impact on overall performance.
Deployment problems — While programmers must ensure that their field lists are complete, run-time errors can still occur during application deployment. This is especially likely when a new database (schema) trigger is defined that references an unfetched field. To work around this type of problem, OpenEdge provides the Field List Disable (–fldisable) client session parameter. This is a run-time parameter that causes the AVM to ignore field lists in the r-code and fetch complete records. This might degrade performance, but allows the application to run until a fix can be made.
Thus, while using field lists can lead to difficulties, the AVM provides a way around most of them. And when used optimally, the performance gains can make field lists well worth the extra attention they might require.