Reducing Round Trips

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss Content Posted by Andy Warren » Reducing Round Trips - Part 2

14 posts, Page 1 of 2

1 2 »»

Reducing Round Trips - Part 2

Rate Topic

Display Mode

Topic Options

Author

Message

Andy Warren

Posted Friday, January 25, 2002 12:00 AM

SSCertifiable

Group: Moderators
Last Login: Thursday, May 09, 2013 12:38 PM
Points: 6,462, Visits: 1,384

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/awarren/reducingroundtripspart2.asp>http://www.sqlservercentral.com/columnists/awarren/reducingroundtripspart2.asp

Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter

Post #2375

Deuce

Posted Thursday, February 07, 2002 4:06 PM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, October 28, 2010 11:22 AM
Points: 152, Visits: 7

I was just about to flame the "cache a recordset in MTS" idea until I read where you took it. Keep the middle tier simple and stateless! Saving the recordset on the client is the right way to go. Remember, you can save the recordset to disk in XML format starting with version 2.6. That said, it may make sense to distribute updates via an alternative means avoiding the database for standard lists (like state) altogether. XML is also a lot easier to read when troubleshooting.

Have fun!

John

Post #26931

Andy Warren

Posted Thursday, February 07, 2002 4:42 PM

SSCertifiable

Group: Moderators
Last Login: Thursday, May 09, 2013 12:38 PM
Points: 6,462, Visits: 1,384

I havent decided yet on the MTS part, needs more thought from me. We used XML early on for debugging, decided to switch to the binary format, smaller, faster, discourages casual tampering. I can definitely see depending on the situation that you might just as well push out new files in a login script, pull them via a web service, etc. We went with the db since everything else was there and we could build a standard way to manage it.

Andy

Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter

Post #26932

K. Brian Kelley

Posted Thursday, February 07, 2002 8:30 PM

Keeper of the Duck

Group: Moderators
Last Login: Yesterday @ 1:13 PM
Points: 6,584, Visits: 1,790

I'm all for keeping the middle tier stateless because of what we're seeing in a current application (in-house built). It means that clients have to pointed at a single COM+ middle-tier server, which eliminates some of the features Application Center Server is supposed to bring such as COM+ routing in order to gain load balancing. Also, because not everything is stateless, the COM+ server becomes a single point of failure.

K. Brian Kelley
bkelley@sqlservercentral.com
http://www.sqlservercentral.com/columnists/bkelley/

K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of Introduction to SQL Server: Basic Skills for Any SQL Server User
| Professional Development blog | Technical Blog |

LinkedIn | Twitter

Post #26933

Steve Jones - SSC Editor

Posted Friday, February 08, 2002 10:58 AM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:30 PM
Points: 31,436, Visits: 13,751

Isn't app center supposed to replicate the info from one server to another? Not sure if this handles the stateless/stateful thing, but it adds overhead. I am for using either the and/or client (cookies) to handle state. Seems the most fault tolerant.

Steve Jones
steve@dkranch.net

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #26934

Antares686

Posted Friday, February 08, 2002 1:19 PM

SSCrazy Eights

Group: Moderators
Last Login: Tuesday, April 09, 2013 12:53 PM
Points: 8,357, Visits: 684

I actually use a similar item already for an app the is user definable and settings are mobile. With our case we have a file assigned by user id that holds the data. What we do is check for the file and if found get a date we have in it for last change. Then we attach to the database and compare the last change on the server table. If they are a match we do nothing more except use these files to populate various controls on the app. Since these apps are for dealing with reps under them they are static to that user. When they add someone we add it to their local file and send to the server and update the last. When they close the app we drop everything. If for whatever reason they go to another desk the same thing happens. Now if the file is not found or the last change don't match we refresh then. This saved us a lot unneccessary network time that using from the database itself was eating up. Plus we reduced overall query needs. All in all good article.

Post #26935

K. Brian Kelley

Posted Friday, February 08, 2002 4:14 PM

Keeper of the Duck

Group: Moderators
Last Login: Yesterday @ 1:13 PM
Points: 6,584, Visits: 1,790

I've not installed App Center Server, but the way it works I don't see how it cannot add overhead. Clients talk to the App Center Server, and the App Center Server farms 'em out based on load. The App Center Server is constantly checking with the COM+ servers to see how they are doing... so there's an awful lot of talking going on that doesn't have anything to do with actually instantiating the COM+ component and executing methods.

K. Brian Kelley
bkelley@sqlservercentral.com
http://www.sqlservercentral.com/columnists/bkelley/

K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server
Regular Columnist (Security), SQLServerCentral.com
Author of Introduction to SQL Server: Basic Skills for Any SQL Server User
| Professional Development blog | Technical Blog |

LinkedIn | Twitter

Post #26936

Steve Jones - SSC Editor

Posted Friday, February 08, 2002 4:53 PM

SSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:30 PM
Points: 31,436, Visits: 13,751

That's a great technique. I did something similar years back with VFP for states and countries (which rarely change). I like flat files for lots of things because there isn't the need to xfer that data from the database constantly.

Steve Jones
steve@dkranch.net

Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help

Post #26937

Andy Warren

Posted Friday, February 08, 2002 5:04 PM

SSCertifiable

Group: Moderators
Last Login: Thursday, May 09, 2013 12:38 PM
Points: 6,462, Visits: 1,384

Flatfiles! Holy database Batman!

Im not a big fan of flat files. I'd rather use a recordset or XML - each gives me powerful tools to work with the data easily compared to a flat file. Not saying there is never a place for a flat file, just that once you've committed to loading MDAC or XML DOM in your app, why not leverage it as much as possible?

Interesting point about dropping everything when the app closes. In our case its entirely possible (even probable) that a DIFFERENT user will use the machine the next day, so we leave the cache on the client. The absolute worst that might happen is that the 2nd user works on a different db and never uses the cache from the 1st db --- but all it costs us is a little disk space.

Andy

Andy
SQLShare - Learn One New Thing Each Day
SQLAndy - My Professional Blog
Connect with me on LinkedIn
Follow me on Twitter

Post #26938

bdloving

Posted Monday, August 19, 2002 1:51 PM

Grasshopper

Group: General Forum Members
Last Login: Sunday, June 21, 2009 8:39 AM
Points: 16, Visits: 2

Ok, I like the ideas in the article, but I need help with the idea of using a persisted recordset as the basis for a listbox or combo box. That is after all why I would want to persist the seldom changing tables.
When you go to use the recordset, are you
just pointing the listbox to the recordset or use VBA code to load it with values?
Thanks

Post #26940

« Prev Topic | Next Topic »

14 posts, Page 1 of 2

1 2 »»

Permissions