Disconnect before 08:00 / after 17:00

Gryphonrider

Has anyone ever experienced a 'time-triggered' disconnect using NAV4SP3 (NL) on a SQL2005 Server?

Before 08:00 and after 17:00 users are frequently disconnected.
Could the backup (scheduler) be interfering? :?

Waldo

This shouldn't happen (off course), and I have not experienced this (yet).
Is it Native or SQL?
Did you recently upgrade?

David_Singleton

Gryphonrider wrote:

Has anyone ever experienced a 'time-triggered' disconnect using NAV4SP3 (NL) on a SQL2005 Server?

Before 08:00 and after 17:00 users are frequently disconnected.
Could the backup (scheduler) be interfering? :?

This is VERY common with Native Database, Many people try to directly backup the Navision database and this locks it and kills the server service.

But as to SQL, then you need to make sure your backup software knows how to talk to SQL.

Gryphonrider

Thank you, Waldo & David Singleton, for your quick responses to my question.

The disconnect occurs using a SQL DB; I'm currently gathering further information regarding this problem.

todro

David Singleton wrote:

Gryphonrider wrote:

Has anyone ever experienced a 'time-triggered' disconnect using NAV4SP3 (NL) on a SQL2005 Server?

Before 08:00 and after 17:00 users are frequently disconnected.
Could the backup (scheduler) be interfering? :?

This is VERY common with Native Database, Many people try to directly backup the Navision database and this locks it and kills the server service.

if the service is killed, who will restart it exactly at 08:00AM ? If it woud be done manually, somebody would know. It it's done automatically, somebody should know about this, too.

It sounds like there is a group policy active...

Gryphonrider

Although I too expected group policy to be active, the SQL 2005 Server and network in question were scanned by external experts and considered to be functioning ok.. I've gathered some extra information regarding this issue:

- there are no login-restrictions active
- backup-scripts start at 22:00
- build of finsql.exe is 4.0.3.23305

Possible workaround (suggested by a collegue): TCP Keepalive-packets are sent to the server, the server responds with TCP Acknowledge-packages. If this operation fails once, the client disconnects. Can I change this (maybe allow some Acknowledge-packages to fail) to get less disconnects?

Second question: do these disconnects have anything to do with the license-file (flf)?

todro

Gryphonrider wrote:

Although I too expected group policy to be active, the SQL 2005 Server and network in question were scanned by external experts and considered to be functioning ok.. I've gathered some extra information regarding this issue:

- there are no login-restrictions active
- backup-scripts start at 22:00
- build of finsql.exe is 4.0.3.23305

Possible workaround (suggested by a collegue): TCP Keepalive-packets are sent to the server, the server responds with TCP Acknowledge-packages. If this operation fails once, the client disconnects. Can I change this (maybe allow some Acknowledge-packages to fail) to get less disconnects?

Second question: do these disconnects have anything to do with the license-file (flf)?

the SQL-Client automatically reconnects to the server in case he lost connection for whatever reason. If the SQL server is temporarily unavailable for backup or maintanance, the client will reconnect as soon as the server is available again, it would not be scheduled for 08:00.

I do not see this related to TCP at all. Did you check the SQL errorlog, windows eventlog ? If the users are disconnected at 17:00 (every day ?), you should find some information in the SQL logs if it's initiated from the server.

Try to ping the SQL server once the connection seems to be down to see whether there is a network related issue.