Thanks for that information.

>>Hello Rick,
>>
>>Persistent data structure against database.
>>
>>Is it a tool that you developed or is there a tool that lets you do that kind of processing. If it's someghing you developed, are you considering selling that tool eventually?
>
>This happens to be for .NET which has the in-memory capabilities that are not available in FoxPro. For FoxPro you always need cursors for this sort of thing, but .NET (using Linq) or JavaScript (using object queries) you can manage even complex data in memory. I don't think this is an option for FoxPro though since it doesn't have a way to query into objects easily (although I suppose one could write such a thing). In FoxPro the other issue is that collections are fairly slow and arrays are unwieldy as hell, and also get very slow once they get large. In FoxPro the only way I could see this working is to actually use cursors to represent that underlying data and that would be somewhat limited in how nested the data can get.
>
>In .NET there's not much that's required to work with this sort of thing. You basically create an object attach properties, collections, nested objects etc. and have a Load and Save method on it that does a blocking read/write and that's about the extent of it. You load it when you need to start using it, then use it in memory and make changes as you need to. When you're done (or you quit) you save the object. Simple.
>
>Example: I'm building a new documentation solution (KavaDocs) that uses an in memory structure to store the documentation content. I have several files with multiple thousands of topics and a content size of about 10megs or so. The entire structure is loaded and kept in memory and saved in the background after each update operation. It's fast and easy to work with. Dataformat on disk is JSON so basic JSON serialization is used load and save. For the largest files it takes 50ms to save, 30ms to load (including serialization).
>
>Once in memory you can use LINQ to query the data and walk the object tree. There are also several libraries that provide a more formal interface (more like a NoSQL database for in-memory and loading/saving) but for the use cases I've used it that's not been necessary.
>
>It's great, low effort solution for 'local' storage and single user access IMHO.
>
>+++ Rick ---