| Subject | Re: [IBO] Need help with a simple OnCallBack for a progressmeter |
|---|---|
| Author | Lester Caine |
| Post date | 2005-07-01T06:47:59Z |
Helen Borrie wrote:
it, the fastest way of doing it is on the server. You set up triggers
and stored procedures to do the processing, and just let it run.
In that situation NOTHING is returned by the server until the operation
is finished! So if you MUST monitor progress then you need to 'SUSPEND'
what the server is doing in order to do so. That in itself is going to
slow down finishing, and you would help that by perhaps only doing the
SUSPEND every 100 or thousand records. At which time you get a check for
each block that is not too wasteful of processing time.
the server, so rather than doing it all at once, the update gets called
for 50 records at a time, and a simple counter displays how many records
have been processed. If something urgent comes up, then I can hold
calling the next update until things have calmed down, and then carry
on. The update takes a lot longer, but I am in control ;)
One import process I run a single record at a time and display the
count, but while I can guess at the total number of records in the raw
file, until I've read them all I don't actually know - It WOULD be nice
if these sorts of systems had a simple count in the header, but back in
the days the system was designed THEY did not know until the magnetic
tape was finished :)
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services
>>Jason's archived response to a similar plea for help suggested using theAs you seem to be simply processing data, rather than wanting to display
>>SELECT
>>Procedure Suspend method of getting the OnCallBack event to fire for each
>>return
>>of a row, but it just not working for me.
>
> I'm not familiar with that particular archived response. I suppose that he
> meant to maintain a record count inside the SP that gets incremented just
> before the SUSPEND call and is passed across to the client as a field in
> the output. Then a callback procedure could read that number...thus
> avoiding the need to count the rows in on the client.
it, the fastest way of doing it is on the server. You set up triggers
and stored procedures to do the processing, and just let it run.
In that situation NOTHING is returned by the server until the operation
is finished! So if you MUST monitor progress then you need to 'SUSPEND'
what the server is doing in order to do so. That in itself is going to
slow down finishing, and you would help that by perhaps only doing the
SUSPEND every 100 or thousand records. At which time you get a check for
each block that is not too wasteful of processing time.
>>Anymore suggestions?I have an update that takes several minutes, and I don't want to block
the server, so rather than doing it all at once, the update gets called
for 50 records at a time, and a simple counter displays how many records
have been processed. If something urgent comes up, then I can hold
calling the next update until things have calmed down, and then carry
on. The update takes a lot longer, but I am in control ;)
One import process I run a single record at a time and display the
count, but while I can guess at the total number of records in the raw
file, until I've read them all I don't actually know - It WOULD be nice
if these sorts of systems had a simple count in the header, but back in
the days the system was designed THEY did not know until the magnetic
tape was finished :)
--
Lester Caine
-----------------------------
L.S.Caine Electronic Services