I suspect your idea for speeding this up can work, but I don't know enough about how your database works to be sure.
How do you get current stock prices? Do you use a web viewer and extract the price from the viewer? Download a set of pricing data from a web site and import it or ???
Stock prices are imported daily into a table within the database. The stock price table holds stock prices for every day. I don't think that this table is the cause of the problem as it just holds static data.
If this table is not the problem and the solution is to copy a snapshot of the entire data in the trade table on a daily basis, what is the best method of doing that?
Ok, that's not quite what I was picturing here.
On the layout where you see things as too slow, first experiment with simpler layout designs to see if excessive conditional formats, unstored calculations etc or other elements are the biggest factor. You can duplicate your layout and then delete elements from your duplicated layout to see what items are the largest source of the "slows" for you. From there, you can explore options for speeding up your layout.
Summary or unstored calculation fields that have to access large numbers of records to compute the needed value is the prime suspect here, but sometimes it's a conditional format that you find you can live without in exchange for faster screen updates.
I found the problem. It relates to many fields within the table that have unstored calculations. I will now try and put those calcluations into a static table and reference the results from there.