January 25, 2002 at 12:00 am
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
February 7, 2002 at 4:06 pm
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
February 7, 2002 at 4:42 pm
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
February 7, 2002 at 8:30 pm
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
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
February 8, 2002 at 10:58 am
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
February 8, 2002 at 1:19 pm
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.
February 8, 2002 at 4:14 pm
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
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
February 8, 2002 at 4:53 pm
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
February 8, 2002 at 5:04 pm
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
August 19, 2002 at 1:51 pm
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
August 19, 2002 at 2:16 pm
I think it varies. Both will work, assigning the recordset to the listbox is definitely easy though may not be powerful/flexible enough. Figure out how you want to handle the binding, then do the caching. Caching is a separate and easily added feature...well, more or less!
Andy
August 22, 2002 at 9:25 am
Ah, a blind spot in my knowledge. <G> So how do you assign an ADO.recordset to a listbox?
Is it just listbox.rowsource = adors ?
August 22, 2002 at 1:54 pm
February 6, 2004 at 7:19 am
Excellent - I esp. like the versioning. I implemented an in-memory cache for an emissions monitoring system [processing 600 calcs/minute], but did not handle the versioning as elegantly as you did here. The calculator runs as service, so little gain in persisting to disk, but that is an excellent idea for some other web site interface [pick lists again!]... May have to go revisit that code.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply