My app handles large databases, sometimes with as many as 32,000 records, and NVFS is a major headache for me.
NVFS is not the only thing that affects performance. Another important factor is the memory speed. Some models, such as the Tungsten T, have relatively slow memory, and perform badly as a consequence. The cheaper Zire 31 performs much better here. NVFS affects all file operations, of which QuickSort is just is an extreme case. Take for instance barcode scanning. Our app normally searches the database record by record. This operation too is adversely affected by NVFS, even though it is sequential and read only. In the case of barcode scanning, where the response time is particularly critical, I resorted to using an optional second index. It is basically as Mr Combee describes, with a slight twist. I store the barcodes in a separate database, together with the unique ids. Performance is acceptable, and the index is still valid if the main database has a different sort order. It can also tolerate a small number of modifactions to the main database. My ideal solution would be for Palm to resume production of the T3, but that is not going to happen. Some of my customers suffer the consequences of NVFS, while others resort to buying non NVFS devices on eBay. -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
