Hi

I am wondering how to handle timeouts for batch type processes.

For example , I have a script that runs through the databases on a server
and backs them up then copies them to a remote server.  This works OK in
EDBMgr except that every three minutes it stops because of a timeout and I
have to click <Yes> to make it continue.

In this case there is a database that, when backed up,  is 106Mb.  The
backup takes 3 minutes and the copy takes 19 minutes.  So have sit and watch
it, so that I can click <Yes> 7 times!  The 19 minutes might be an
exaggeration as I left the room to make a cuppa and it might have been
waiting for me to come back and click it again.

I presume the "3 minutes" that I roughly timed is because the server was set
up with default values and the timeout is 180 seconds.

There are three scenarios where I envisage this could be a problem.  The
database is not a particularly large one and I have no control over the
database sizes or of the line speeds for transferring the backups to remote
server, so I can't set the timeout to (say) 3 hours and just hope that it
enough.  Presumably a really long timeout interval is undesirable ...

1.    As above, running a script in EDBMgr.

2.    Running scripts using TEDBScript in Delphi.

3.    Running the scripts as JOBs.

Scenarios 2 and 3 are the most likely in a live situation.

Cheers

Jeff

--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz

I have realised that the timeout of 180 seconds is on the session, not the
database, but my questions remain.

"Jeff Cook" <jeffc@aspect.co.nz> wrote in message
news:4225D582-3154-4B07-8333-7675399EFF92@news.elevatesoft.com...
> Hi
>
> I am wondering how to handle timeouts for batch type processes.
>
> For example , I have a script that runs through the databases on a server
> and backs them up then copies them to a remote server.  This works OK in
> EDBMgr except that every three minutes it stops because of a timeout and I
> have to click <Yes> to make it continue.
>
> In this case there is a database that, when backed up,  is 106Mb.  The
> backup takes 3 minutes and the copy takes 19 minutes.  So have sit and
> watch it, so that I can click <Yes> 7 times!  The 19 minutes might be an
> exaggeration as I left the room to make a cuppa and it might have been
> waiting for me to come back and click it again.
>
> I presume the "3 minutes" that I roughly timed is because the server was
> set up with default values and the timeout is 180 seconds.
>
> There are three scenarios where I envisage this could be a problem.  The
> database is not a particularly large one and I have no control over the
> database sizes or of the line speeds for transferring the backups to
> remote server, so I can't set the timeout to (say) 3 hours and just hope
> that it enough.  Presumably a really long timeout interval is undesirable
> ...
>
> 1.    As above, running a script in EDBMgr.
>
> 2.    Running scripts using TEDBScript in Delphi.
>
> 3.    Running the scripts as JOBs.
>
> Scenarios 2 and 3 are the most likely in a live situation.
>
> Cheers
>
> Jeff
>
> --
> Jeff Cook
> Aspect Systems Ltd
> www.aspect.co.nz
>
>

Hi again

"Jeff Cook" <jeffc@aspect.co.nz> wrote in message
news:4225D582-3154-4B07-8333-7675399EFF92@news.elevatesoft.com...
>
> 1.    As above, running a script in EDBMgr.
>
> 2.    Running scripts using TEDBScript in Delphi.
>
> 3.    Running the scripts as JOBs.
>

3.  I have just run an experiment with a JOB that ran for 27 minutes with no
obvious issues.  That presumably means that timeouts aren't an issue with
JOBs at least.

--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz

Hi Jeff,

> I am wondering how to handle timeouts for batch type processes.

What I'm doing in my app is creating a event handler to use for connection
timeouts on processes that I expect can run for extended periods of time
without sending progress back to my app.    Just before I start the long
running process, I set the session OnRemoteTimeout to the event handler and
then set it back to null when the process is done so.   This prevents the
timeout message even if the process runs for hours.

The event handler is simple:

procedure TConnectionDM.PrimarySessionNoTimeout(Sender: TObject; var
StayConnected: Boolean);
begin
StayConnected:=True;
end;


---------------------------------------
Terry Swiers
Millennium Software, Inc.
http://www.1000years.com
http://www.atrex.com
---------------------------------------

"Jeff Cook" wrote:

>3.  I have just run an experiment with a JOB that ran for 27 minutes with no
obvious issues.  That presumably means that timeouts aren't an issue with
JOBs at least.<

Jeff,

This makes sense since with option 1 & 2 the TCP/IP connection from the database to the client was timing out because the task took more than 3 minutes. With option #3, the task is run on the server so there is no TCP/IP connection to time out.

When using a client that times out, the easiest way would be to increase the amount of time for "Remote Timeout=180" but like you said, you don't know how long it will take.  When doing long task from the client, the TEDBSession component has a RemoteTImeOut property that could be boosted (temporarily) to a high enough value (2 days?) to fix the timeout problem. If you do this I'd recommend you uniquely name the SessionName to something like "sesLongBACKUP" so you can easily recognize it on the server as a long backup task. Same with the user name "LongBackup" so it stands out better when using:

select * from configuration.serversessions!
select * from configuration.serversessionlocks where objectname='mytable'!

You could also lower "Remote Ping Interval=60" so it tries to ping more than once a minute, but that may not work if the task uses 100% of the client's CPU.

Barry

Hi Terry and Barry

Thanks for that, I think I have that clear.  My plan now is:-

1. for running long scripts in EDBMgr, create a "LongSession" in EDBMgr as
per Barry's suggestion
2. for running scripts in Delphi, use the OnRemoteTimeout event to
StayConnected as per Terry's suggestion
3. for JOBs do nothing - and thankfully this will be the commonest
situation.

Thanks again - three heads are better than one, especially when the "one" is
mine.

Cheers

Jeff

--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz