leehambly
2016-11-08T14:24:50Z
Hi,

Have had a quick scan and cannot see any obvious question regarding this - apologies if I have missed a previously posted answer...

Ok, so we have a small access app - and it does next to nothing...

1. Connects to a local SQL server and retrieves some data
2. Displays the data on a form using iGrid

This morning, we had an internet outage - the internet was down for around 1 hour.
This outage did not impact the local SQL server and as such we would expect the app to continue to work fine.
However, the app was taking around 20-30 seconds to load rather than the usual 2 seconds.

So - my question - might it be the iGrid that is causing this? Is it pinging for a license key or flag somewhere?? It does eventually start fine, but just sits there, I am assuming waiting for a timeout. There is virtually no code in this app... its one form, one control and one routine to load the data to the control so... Thoughts?

Cheers for any response ๐Ÿ™‚
Igor/10Tec
2016-11-08T14:53:32Z
iGrid does not contain any Internet calls or something like that.

Why do you think the bottleneck is inside iGrid?

The only thing I can think about is that this problem happened in ADO/DAO, when iGrid tried to read the recordset data using its usual code.
leehambly
2016-11-09T11:43:53Z
Originally Posted by: Igor/10Tec 

iGrid does not contain any Internet calls or something like that.

Why do you think the bottleneck is inside iGrid?

The only thing I can think about is that this problem happened in ADO/DAO, when iGrid tried to read the recordset data using its usual code.



Ok, cheers for the reply Igor...
The reason why I thought it might be the iGrid, as a first place to look, is simply because there is only one "non-trivial" control on a single form in the entire application, and that is the iGrid. The trivial controls being command buttons and labels.
Obviously, I can't really delve too deep inside that - whereas the other code, I can debug and establish why there is an issue - but asking this question, first, closes that "unknown" from the get-go ๐Ÿ˜›