March 3, 2002 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/awarren/reducingroundtripspart3.asp>http://www.sqlservercentral.com/columnists/awarren/reducingroundtripspart3.asp
September 23, 2002 at 1:39 am
"ADO recordsets have a filter method, the only downside is that it only accepts one where clause."
...do you mean the "Find" method ? The "Filter" method can have many items in the Where clause.
John
May 14, 2004 at 2:11 am
Reducing Client/Server traffic
Session Variable Lists can be controlled as a just-in-time requirement, instead of loading them ALL at Login… We first were pulling in all of our required drop-down data as soon as a user logs in, and then would reuse these to repopulate (from session) as needed on all forms and pages.
Well we started this way and then needed a refresh process for when the drop-data gets changed by the current user. Example: A user needs to assign an employee to a new route/task (via drop-down) and also add new devices prior to assigning them as well (via drop-down).
Simple: The form which adds new devices (sets a refresh flag); an include file of all drop-down selections is invoked prior to the usage of all forms and the new session list is built. The user now has the new drop-down data and can continue in finishing the original assignment process.
Update: So now all the selection lists are being made at login and again as needed when the refresh flag is set.
The next step was to use JITS (just-in-time-selection) drop-down builds based on the form requirements as each page is called, instead of building them all at once (during logon). We created an include ASP procedure which we call with the form name prior to using the form each time it is used. This procedure builds all drop-down lists (only if not already built). This helps to eliminate the big wait just after logon, which was getting pretty obvious, and eliminated the extra work being done for forms (drop-down) requirements which were not even being used.
We researched our “logon history” table and found that most of our users were logging in to accomplish the following (as a one user session):
1. Multiple adds, updates, deletes within the same form types, same logon.
2. Most of the previous data changes were followed by queries on same data.
NOTE: Our inserts are data entry type forms, so the user can repeatedly enter new records as quickly as they can type and hit enter. So within the first call to a form, we load the required session drop-downs (this form only), and then reuse them as needed.
Our review also showed that each logon would concentrate on only a small percentage of our total forms at each logon session. Meaning they would logon again and again throughout the day for doing very different and selected processes.
Our savings in session variables and SQL requests has become quite noticeable!
Coach James
May 14, 2004 at 12:49 pm
I am wondering about the statements regarding nocount. I agree that it should be set on (not only for performance but because of problems with MS data access technologies throughout their history), but a quick check of the statistics in Query Analyzer report back a single round trip for a stored proc doing a number of updates regardless of the nocount setting (though a bunch more traffic + packets received for the stored proc executed when nocount is off)..
May 18, 2004 at 5:45 pm
Fair point - I'll see if I can find time to do a network capture to be sure of what is really going on. QA is probably right, but I like to see live to be sure!
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply