Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Reducing Round Trips - Part 2 Expand / Collapse
Author
Message
Posted Friday, January 25, 2002 12:00 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Today @ 9:01 AM
Points: 6,705, Visits: 1,680
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
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #2375
Posted Thursday, February 07, 2002 4:06 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-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
Posted Thursday, February 07, 2002 4:42 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Today @ 9:01 AM
Points: 6,705, Visits: 1,680
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
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #26932
Posted Thursday, February 07, 2002 8:30 PM


Keeper of the Duck

Keeper of the Duck

Group: Moderators
Last Login: Thursday, April 03, 2014 10:06 PM
Points: 6,621, Visits: 1,851
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
Posted Friday, February 08, 2002 10:58 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:56 PM
Points: 32,771, Visits: 14,935
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
Posted Friday, February 08, 2002 1:19 PM
SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: Moderators
Last Login: Yesterday @ 3:54 PM
Points: 8,369, Visits: 733
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
Posted Friday, February 08, 2002 4:14 PM


Keeper of the Duck

Keeper of the Duck

Group: Moderators
Last Login: Thursday, April 03, 2014 10:06 PM
Points: 6,621, Visits: 1,851
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
Posted Friday, February 08, 2002 4:53 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:56 PM
Points: 32,771, Visits: 14,935
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
Posted Friday, February 08, 2002 5:04 PM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: Moderators
Last Login: Today @ 9:01 AM
Points: 6,705, Visits: 1,680
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
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
Post #26938
Posted Monday, August 19, 2002 1:51 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

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 »

Add to briefcase 12»»

Permissions Expand / Collapse