DOCUMENT:Q191637 13-AUG-1999 [foxpro] TITLE :PRB: SEEK Returns Different Results Depending on No. of Fields PRODUCT :Microsoft FoxPro PROD/VER:WINDOWS:3.0,3.0b,5.0,5.0a,6.0 OPER/SYS: KEYWORDS: ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Visual FoxPro for Windows, versions 3.0, 3.0b, 5.0, 5.0a, 6.0 ------------------------------------------------------------------------------- SYMPTOMS ======== The SEEK command returns different results depending on the number of fields in a table. If there are 62 or less fields in a table, the SEEK command returns false when another user unmarks a record that has been marked for deletion . If there are 63 or more fields in the table, the SEEK command returns true. The expected result would be that SEEK would return false. Make sure that the SET REFRESH is set to zero and that SET DELETED is on. CAUSE ===== This seems to occur because FoxPro reads the table from the hard drive and retrieves the data if there are more than 62 fields in the table. If there are 62 fields or less, then FoxPro reads the data from the cache. STATUS ====== This behavior is by design. MORE INFORMATION ================ The preceding scenario depends on having two sessions of FoxPro open and marking a record for deletion in a table in the first session, then opening the same table in a second session. After switching back to the first session and recalling the record, the SEEK command returns false if there are 62 or less fields in the table or it returns true if there are 63 or more fields in the table. The SET REFRESH must be set to zero and SET DELETED ON, for this to occur. Steps to Reproduce Behavior --------------------------- 1. Open two sessions of FoxPro. Issue the SET REFRESH TO 0,0 command in both of the sessions. 2. Open a table, shared, that contains 62 or less fields in the first session of FoxPro. Mark the first record for deletion and move the cursor off the record. 3. Switch to the second session of FoxPro and issue a SET DELETED ON. Open the same table, shared, and set the order to one of the fields that has an index. 4. Switch back to the first session of FoxPro and unmark the deletion from the first record and move the cursor off the record. 5. Switch back to the second session and issue the following command, giving the SEEK command the value of the field that is indexed in the first record that you unmarked for deletion the first FoxPro session: WAIT WINDOW IIF(SEEK(""), ".T.", ".F.") NOTE: The SEEK command returns false. 6. Follow steps 2-5 using a table with 63 or more fields. Note that the SEEK command now returns true. Additional query words: kbVFp300b kbVFp500 kbVFp500a kbVFp600 kbXBase KbDBFDBC kbDatabase ====================================================================== Keywords : Technology : kbVFPsearch kbAudDeveloper kbVFP300 kbVFP300b kbVFP500 kbVFP600 kbVFP500a Version : WINDOWS:3.0,3.0b,5.0,5.0a,6.0 Issue type : kbprb ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 1999.