I will have to weigh the speed versus the upsizing advantages in my particular case. However, I know from experience that a number of my customer have busy networks. Some of them are private schools which where every student and classroom is networked. At certain times of the day network performance is a serious problem.

I may also consider developing a class that has the same interface as a cursoradapter but accesses tables natively, perhaps I can have the speed I now enjoy and later easily replace this special class with a true cursoradapter.

I will just have to work through the issues and find the best solution.

Thanks
Simon



>Hi Simon.
>
>>For example I have a customer history file with roughly 300K records. I was assuming I would set a where condition in the SelectCMD so that as the user moves through the customer file they could see the account history and only the records for the current customer would be retrieved. This works but it takes much more time to retrieve the records (even with rushmore optimization) than my current method of using "Set Key to " to limited the records to the current customer.
>
>I don't think this is a CursorAdapter issue but the difference between doing a SQL SELECT and accessing a table directly using SET KEY TO (which is extremely fast). So, yes, performance isn't a good in this scenario. However, if you were to upsize this app, you couldn't use that technique.
>
>Doug