Good questions Mike. I'm not the best to answer them, but I'll have a try. 1. Rather than saying that 9 is more dependent on indexes than 8, I think it's more accurate to say that it can make much better use of them--and it puts the power to control this in our hands. The power--and the obligation. 8 uses a narrower range of indexes--and handles them implicitly and invisibly. 2. Yes, the ability to add a custom indexes to interim result tables is (I think) the main reason to use a temporary database and a temporary table. 3. All temporary databases (and the tables and other components they contain) can be explicitly destroyed with DROP. When a temporary database is implicitly dropped depends on the type of temporary database created. There are two different types. See the notes in the next section below. 4. but it then just shows up as another table in the project pane with a temp name that isn't the name in the temporary database
That's not quite right. Yes it seems confusing. Again, to clear it up we need to distinguish the two types of temporary database (below). 5. Yes. As many as you like. 6. More "why" would be great.
Absolutely. More "what" as well!
So, the two types of temporary database (or temporary datasource). The manual is less than helpful on this point, because it starts off with one type (the less obvious one), then switches to the other type partway through, without explaining the difference. Type 1 The first type (in the manual) is created like this. CREATE DATASOURCE [Scratch] (PROPERTY 'Type' 'manifold'); Note the lack of any connection string--that is what makes it a temporary database. If we specified a connection to an existing source, then this would be exactly like using Create Data Source in the GUI. But here we're not specifying an existing source, so the new datasource is (a) local and (b) empty. It is like a new Manifold project, contained within the current project--and visible in the Project tree. (It is said to be backed by a temporary .map file--though I haven't been able to figure out where that is.) A temporary database of type 1 persists until the project is saved (unless it is deleted or dropped). However, changes remain volative (i.e. temporary) unless they are explicitly saved, either by invoking the Save command from the context menu for the database, or by saying yes to the "Save changes to child data source?" prompt when saving the project. Type 2 The second type of temporary database is created like this.CREATE ROOT [Scratch]; This new "root" is also a database/datasource, but different from type 1 in three main ways (perhaps there are others). First, it does not appear in the Project pane--it is invisible to the user. That's quite nice, since it means we can just use it, without distracting the user (or ourselves) unnecessarily. Secondly, it can only be accessed from within the Command window or Query component that created it. (And different windows and queries can have temporary databases with the same name.) Third, it does not persist. Its lifetime is tied to the state of the Command window or Query component that "owns" it. Close the Command window, and the temporary database goes with it. Close the Query, and the temporary database is also gone--and must be created again next time the query is opened and run. So if type 1 is a public temporary database for the project, Type 2 is a private temporary database for one window or component. When would we want to use type 1--given that also we have type 2? It persists, is shared, and is visible. So maybe we want to write some temporary data with one batch of queries, then perform some GUI operations on the result, then address the data with another set of queries, and so on. Possibly with project saves in between. But in that case, why not use ordinary fixed tables (and drawings, and so on), within the project root? I don't have an answer for that one. Perhaps the main thing type 1 adds is confusion.
For the mechanics of using temporary databases of type 2, as well as Adam's notes above, the examples in these threads might be useful (though some of the code is incomplete or flawed in other ways). http://www.georeference.org/forum/t138060.50#138161 http://www.georeference.org/forum/t138305.18#138380
|