That seems to be the kludge I'll go for. Additional parameters will specify the service name and exe name. This will make a copy of the exe, register the service, and make a registry entry that links the exe name to the service name. Then, at run time, I can get the module (exe) name, look up the service name in the registry, and then determine the registry key for that service's parameters. X| This is neither elegant nor something to be proud of, but time is money. Thanks Don't worry, nobody lives forever.

I downloaded the trial of SciTech .NET Memory Profiler 2.0 (http://www.scitech.se/memprofiler/Default.htm). This tool helped me find the memory leak. FWIW: When I create an event handler for a multi-line text box, the form sits in memory after being closed. I removed the handlers and the form is removed! I've never seen anything like it. I have NO CODE in the handler, just this: Private Sub TextChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles txtTextbox1.TextChanged End Sub And if I remove it, my 1K+ form will remove itself from memory. If the handler is in there, no number of GC.collect statements will free the damned thing. Garbage I say GARBAGE !!! Don't worry, nobody lives forever.

The DataSet will load the different levels of nodes into seperate tables, but will create relationships between those tables for you. The property table that is created in the DataSet should have a relationship to the sellingpoint table, which could be accessed through the DataSet.Tables(0).ChildRelations collection. Using this DataRelation, you can access the sellingpoint children of a property row by doing DataSet.Tables(0).Rows(0).GetChildRows(DataRelation). There are other ways to do this as well. Just take a look at the help for DataSet and DataTable for more information. Or, to get an idea of exactly what is in your DataSet after loading the XML, set a breakpoint in your code, and do a QuickWatch (right click on an object after breaking into code during debug of your application) of your DataSet.

Well, if you have created the class for handling your dataset (Generate code or something), then you should be able to use a function of propertyRow, which named like GetSellingpointRows(). If you don't see it, then you can try using GetChildRows anyway. I can't help you much with VB, but here is a link to IBuySpy[^]. You can download a VB version and see how they did this (look in PortalCfg.vb and Components/Configuration.vb): Philip Patrick Web-site: www.stpworks.com "Two beer or not two beer?" Shakesbeer

Are you wanting to "pretty print" them? If so, the script would depend on the log format you chose and what fields you chose to log. You'll need to use the Scripting.FileSystemObject if you are truly in ASP. If you're using ASP.Net there are other methods. If not, they are just text files, so you can just link directly to them and they will display in the browser, no assembly required.

have you enabled that drive for indexing service, thats one of those possible reason. Cheers, Kannan