> is there any way for cf to maintain state > with a COM object (dll) such that it could call > to it, and then hit it again, yet not having > to instantiate it again?
You can stick it in a persistent scope (Server, Application, Session), but you may run into performance problems - even Microsoft has long recommended that you not persist COM objects that way in ASP. I have seen that done in CF applications, though. If you're interested in maintaining state so that you can maintain the property values within the object, you might just copy them into persistent CF variables, then repopulate the object's properties the next time you instantiate the object. If you just want to avoid the overhead of instantiation, and you wrote the COM object yourself, you might rewrite your object to use MTS. This is actually pretty easy to do, if you're using Visual Basic - it's about three lines of code, if I recall correctly. Then, your CF code would create and destroy the object the same way it is now, but behind the scenes MTS would handle object pooling for you, substantially reducing the time spent. I did this for something a while back, and was pretty pleased with the results. You don't get the full benefits of MTS when using COM from CF, but the object pooling part works pretty well. It does make deployment a bit more difficult, though, as you have to reregister the object with MTS any time you recompile it, if I recall correctly. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
