macc2010


>Also, as in a large application, I have some reports that the user does not use frequently, and in these cases, the index could not to be the appropiated for the select, and I would like to have a properly way to cancel the report as I had with BDE.

The only way I know of that's built in is the Continue parameter in the OnProgress event.

From your earlier posts it sounds like you have the source so you could hack that to give the result you want (if it works Tim might be interested in adding it in to the product).

Another option is to move the query to a background thread, write out a temporary table, and if a cancel button is clicked just forget about using it. You still wouldn't be able to give progress feedback

Roy Lambert

>From your earlier posts it sounds like you have the source so you could hack that to give the result you want (if it works Tim might be interested in adding it in to the product).

Yes, I confirm you that I have the source code.

I think that Tim has not seen this issue very interesting because it would slow the low level system, but with this modification, the applications would be able to cancel a query at any stage of query execution.

It would be perfectly understandable that the scanning subsystem records would not give percentages, since it is not possible to give them, but it could give messages indicating that the query is working with the intention of you can cancel it at any time. If done well, it should not affect to performance. I have clear that parts of the code that would need to be modified, but I would not like to have a patch over the heart of a library of a third party. The problem is that you can not do descendants of these classes because this part of the sources is not intended to be personalized for a final programmer of the library. I will try to do the changes and I will send the sources to Tim to see if he like this solution, or if he can do this part of the library descendable to be able to modify the source and include this modification without having to patch the source each time that the sources changes.


Thank you and best regards.

Hello Roy,

To be more precise, there are a lot of procedures where there are index scanning and row scanning in while loops before the first OnProgress with the percent of progress is called. The query subsystem stay "frozen" all the time that this code is executed over tables with lot of data without index optimizations. I think that with a simple new event called for example OnScanningRows that would be called into these loops would be enough to give to third programmers like me the opportunity to take actions during this process.

Thank you and best regards.

The truth is that I would like to have the opinion of Tim on this topic.

macc2010

<<If done well, it should not affect to performance.>>

That was my opinion until I started thinking about it after the discussion with Tim.

Take the simple case where a row scan is happening (this is what causes the biggest slow down in query performance) you have to decide where to place the function call. If you check just once at the end of the row scan that's not going to give you what you want because this may be what's taking all the time. If you check after every row this will hit performance. Assigned my be a quick test but say 100,000 of them add up, and a function call may not take a lot of time but again 100,000 of them add up. Then there's the real kicker - what the programmer puts in the event.

The final nail in the coffin, as far as I can see, is obtaining user input. For the user to be able to click on a button to ask that the query is cancelled means that Windows must have been processing messages. I'm not a low level programmer so I don't know just how calling an event achieves this. I assume it does with the current OnProgress event (never tried it) but all of the heavy lifting has been done by then and the bit of work left won't be to impacted by the equivalent of an Application.ProcessMessages every 100ms

Roy Lambert

macc2010

>The truth is that I would like to have the opinion of Tim on this topic.

Best way would be to open a support ticket, otherwise you just have to wait for him to show up here.

Roy Lambert

Roy Lambert wrote:

macc2010

>The truth is that I would like to have the opinion of Tim on this topic.

Best way would be to open a support ticket, otherwise you just have to wait for him to show up here.

Roy Lambert

Thank you Roy,

The new event only would be called if it is assigned to a procedure to respond to the event, if not, it is not called and the performance should not be affected. It would be responsability of the end programmer to implement code that do not affect to the performance, for example calling to the window every x seconds, not in every call to the event procedure.