NETWORKIO waits when using Access 2002 form front end to SQL Server 2000
I am working on a system that uses Access 2002 to provide a front-end to a SQL Server 2000 database via ODBC linked tables. The system started life as an Access database and has been moved to SQL Server using the Upsizing Wizard. I have been gradually moving logic from the Access VBA to SQL Server stored procedures, UDFs, triggers etc., thus moving some of the strain from the client to the server.
We have noticed that the system tends to slow down through the day and looking at the activity on SQL Server I can see a number of NETWORKIO waits. Tracing this back, I can see that these are caused by certain forms in the system, with the Wait starting when the form is opened and continuing until the form is closed. Closing and re-opening the forms seems to speed up the system for a while.
The nature of the system is such that users tend to keep forms open for a large part of the day. And the users are reluctant for me even to put timeouts in the forms to close them after periods of inactivity.
Not all forms cause this problem and I have tried to compare good forms to bad ones to see whether there is a way of preventing these Waits. I have also tried creating new forms based on the same tables and I get the same problem, so it is probably more to do with the tables themselves rather than the forms.
Has anybody else experienced this behaviour, and is there anything that I should be looking for in the tables (or indeed the forms) that could cause these Waits?
We have noticed that the system tends to slow down through the day and looking at the activity on SQL Server I can see a number of NETWORKIO waits. Tracing this back, I can see that these are caused by certain forms in the system, with the Wait starting when the form is opened and continuing until the form is closed. Closing and re-opening the forms seems to speed up the system for a while.
The nature of the system is such that users tend to keep forms open for a large part of the day. And the users are reluctant for me even to put timeouts in the forms to close them after periods of inactivity.
Not all forms cause this problem and I have tried to compare good forms to bad ones to see whether there is a way of preventing these Waits. I have also tried creating new forms based on the same tables and I get the same problem, so it is probably more to do with the tables themselves rather than the forms.
Has anybody else experienced this behaviour, and is there anything that I should be looking for in the tables (or indeed the forms) that could cause these Waits?
ASKER
Thanks for the response arbert.
The 'Record Source' on the form is set to a local Access table, which is a linked-table linked via ODBC to a SQL Server view based on a couple of sub-tables.
So there's no explicit dynaset created in the VBA code from a proc or dynamic SQL. Just for info, I do include SET NOCOUNT ON in all my procs.
I'm used to seeing NETWORKIO waits come and go, but then I'm more used to web-based systems or VB front-ends where I control the creation and destruction of recordsets. With this Access front-end, the waits just build up and up (for example, I'm looking at Enterprise Manager now and there are 5 NETWORKIO waits, the largest being 906922) and they are not released until the users close the forms. Maybe these waits aren't a problem, but clearing them certainly seems to improve performance.
Incidentally, there are only 6 users on a 100MBit LAN and about 29000 rows of data in the table in question (which Access is displaying 1 at a time via the form).
The 'Record Source' on the form is set to a local Access table, which is a linked-table linked via ODBC to a SQL Server view based on a couple of sub-tables.
So there's no explicit dynaset created in the VBA code from a proc or dynamic SQL. Just for info, I do include SET NOCOUNT ON in all my procs.
I'm used to seeing NETWORKIO waits come and go, but then I'm more used to web-based systems or VB front-ends where I control the creation and destruction of recordsets. With this Access front-end, the waits just build up and up (for example, I'm looking at Enterprise Manager now and there are 5 NETWORKIO waits, the largest being 906922) and they are not released until the users close the forms. Maybe these waits aren't a problem, but clearing them certainly seems to improve performance.
Incidentally, there are only 6 users on a 100MBit LAN and about 29000 rows of data in the table in question (which Access is displaying 1 at a time via the form).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Yes, I know Enterprise Manager isn't the best thing at the world at refreshing, but I was just taking a quick look. If you refresh the current activity and then look at the Process Info, the waits are still there, just with bigger numbers (the one I mentioned earlier is at 1061360 now).
I'll try building an ADO recordset and binding to that to see if it makes a difference. I'll let you know.
I'll try building an ADO recordset and binding to that to see if it makes a difference. I'll let you know.
ASKER
Just got back to this after some time looking at other stuff.
It does seem to behave better using ADO. Unfortunately the application is very large for an Access app and my client isn't too keen on me changing it to manually bind all the forms to ADO recordsets. It also doesn't lend itself to converting to an Access project as it uses a great many local temporary tables while doing calculations (a hang-over from its stand-alone Access days). I have encouraged the users to close the forms when they are not using them and this seems to help, so I think I'm going to let sleeping dogs lie on this one and close the question down. Points are yours Arbert.
It does seem to behave better using ADO. Unfortunately the application is very large for an Access app and my client isn't too keen on me changing it to manually bind all the forms to ADO recordsets. It also doesn't lend itself to converting to an Access project as it uses a great many local temporary tables while doing calculations (a hang-over from its stand-alone Access days). I have encouraged the users to close the forms when they are not using them and this seems to help, so I think I'm going to let sleeping dogs lie on this one and close the question down. Points are yours Arbert.
Basically, some networkio waits are normal--just depends on the amount of data, speed of the network, number of users, etc. Just means sql is pushing the data faster than the client can handle it (or respond back).