At that is what I would like to prevent. Right now it takes time to fill the browse. But once loaded scrolling up and down is fast enough. What annoys me is that resizing the window triggers a reload.Normally that is good because you can be sure the data is up to date. But is this case it probably won’t be changed.
The real answer is probably that convince the users to start with a smaller date range.
OK, that clarifies why loading in MS SQL Management Studio is faster compared by loading in the browse.
Thanks for this clarification. Using BUFFER wil not help me in this case.
Yes, a good approach with the old driver is to make the default of the browse filter to a limited result set (assuming a good key for the filter).
In the long run I think switching to the (very expensive) new driver is going to become the norm for serious/commercial programs. It allows programs to be fundamentally better, without any code changes. It is expensive, but ultimately the value dwarfs the price.
True this won’t work in this particular browse that is very clear now. But what you are saying when using is for reports is interesting. I think I can use the same trick for looping over a view.
Thank you for this clarification.
Maybe I can figure an easier way: In WM.TakeResize it mus be possible to prevent reloading some way.
However I am getting very curious on your new SQL driver. Based on what you are telling it will have great advantages.
Is it possible to mix the new and old driver in the same dictionary? Or to be more precise: Can I have a SQL side view which uses the new driver in the dictionary while the real tables still use the old driver?
If so that would be great, because the large data set I am talking about here comes from a complex SQL side view (several joins, sub queries and a Union).
Yes you can mix drivers in the same dict. Just like you can mix say SQL and TPS drivers.
Your understanding of a “server side view” however is incomplete. You’re thinking of it as a pre-formed result set on the server. Its common for Clarion people ro think in this way.
In fact its nothing more than a SQL SELECT statement. Whether it is pre-stored in the server, or sent from the client on each use, is the same. In both cases the server builds the result set “on demand”. It is not pre-calculated. There is no performance gained by it being a “server side view”.
As mentioned earlier, any sql can be sent to the server via the SQL command.
I’d also add that while you can mix drivers, you won’t. Once you gave the new driver you’ll use it for all your tables - there simply would be no point in not doing that.
I know it is just a SQL statement and certainly not a result set.
But the advantage to have a view defined on the server is that you add that view in the dictionary as if it is a table. The Clarion templates see it then as a normal table making it is possible to use it for example in the browse template.
If your tables is for read only go to global properties, action, individual file overrides and change the file open mode to read only and the cursor don’t is created, i always uses complex server side views and import to dct with a real big database and the response is impresive