Hi all,

I have an application out with a small number of clients.  It has been in
production for about 5 years so it's pretty stable.
The issue I've got at the moment is with the receipting system, it has a
header and detail file to hold the receipts.  There are about 800,000 detail
records.
When a new receipt is added it inserts the new header record, then inserts
one or more detail records, generally no more than 3 detail lines.
The Save receipt process updates some totals in other tables and all this is
done in a transaction.

From time to time the users complain that it can take "ages" to save.  I put
some timings into track this and found that the commit call, which normally
takes less than 1 second to compete, sometimes takes 30 seconds.

This condition comes and goes.  On one occasion when it became very slow
they kicked all but one user off the program and that user still experienced
very slow save times.

I have yet to try and look closely at what happens during commit, but this
sounds like a server/network thing to me.  But I thought I'd wave my hand
and see if anyone has ideas.

I'm using D7 and DBISAM 4.30.1 in client server mode.  The app runs across a
Gigabit LAN and they have a decent high end server with about 30 people on
it.  Although as I said above the issue is evident with only one person in.

Thanks,
Bruce.

Probably a network hickup

Bruce Rogers wrote:

> Hi all,
>
> I have an application out with a small number of clients.  It has
> been in production for about 5 years so it's pretty stable.  The
> issue I've got at the moment is with the receipting system, it has a
> header and detail file to hold the receipts.  There are about 800,000
> detail records.  When a new receipt is added it inserts the new
> header record, then inserts one or more detail records, generally no
> more than 3 detail lines.  The Save receipt process updates some
> totals in other tables and all this is done in a transaction.
>
> From time to time the users complain that it can take "ages" to save.
> I put some timings into track this and found that the commit call,
> which normally takes less than 1 second to compete, sometimes takes
> 30 seconds.
>
> This condition comes and goes.  On one occasion when it became very
> slow they kicked all but one user off the program and that user still
> experienced very slow save times.
>
> I have yet to try and look closely at what happens during commit, but
> this sounds like a server/network thing to me.  But I thought I'd
> wave my hand and see if anyone has ideas.
>
> I'm using D7 and DBISAM 4.30.1 in client server mode.  The app runs
> across a Gigabit LAN and they have a decent high end server with
> about 30 people on it.  Although as I said above the issue is evident
> with only one person in.
>
> Thanks,
> Bruce.

Bruce,

<< From time to time the users complain that it can take "ages" to save.  I
put some timings into track this and found that the commit call, which
normally takes less than 1 second to compete, sometimes takes 30 seconds. >.

I would guess that something is occurring on the server that is preventing
the writes from taking place in a reasonable amount of time.  Are there any
regularly-scheduled AV scans, backups, automatic updates, etc. ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Yes, that does sound like it.  Thanks guys.

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:56A9A887-AE8F-42EE-BC99-CE884434B96D@news.elevatesoft.com...
> Bruce,
>
> << From time to time the users complain that it can take "ages" to save.
> I put some timings into track this and found that the commit call, which
> normally takes less than 1 second to compete, sometimes takes 30 seconds.
>  >.
>
> I would guess that something is occurring on the server that is preventing
> the writes from taking place in a reasonable amount of time.  Are there
> any regularly-scheduled AV scans, backups, automatic updates, etc. ?
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com