>Hi Experts,
>
>In my n-tier apps, for transactions like Invoices, I usually pull ALL invoices header records to a grid for the user to view and search. Then, there are buttons for CRUD functionality in the same form. Alas, this obviously has performance issues if records reach well beyond 100,000 over the internet (this seems to work reasonably fast enough over LAN) as this would take quite a while. Heck, I wouldn't sit around and wait that long either. =)
>
>I would like to ask what should be the proper or industry practice to such forms. Kindly share how you guys do it.
>
>Thanks In Advance. Love live the Fox!
>
>Dennis

Hi Dennis

I have a form class with a search area at the top and a grid below it. I have a toolbar with add/delete/next/previous/top etc. The user builds search criteria and a navigation cursor is populated with results in the same form. That cursor is displayed in the grid. It only shows some columns, let's pretend there are just 5 columns. Let's also pretend that the table itself has 50 columns. At worst if I pull 100 rows of 50 columns that would be 5000 cells. By using a narrow cursor for the navigation, assuming the search results in 100 rows, that is 500 cells of data so far. The user picks a record in the list and activates a data entry page. The 50 columns for that row are grabbed into a data entry cursor. So now I'm up to 550 cells instead of 5000 cells. That keeps things fast on a LAN you can see the difference.

I also use create cursor to create the blank cursors when the form loads instead of running the queries with dummy values or NoDataOnLoad. Create cursor is faster than running a complex query even with NoDataOnLoad or WHERE .F.

My web apps use paging and this two cursor technique.