However, if I want to export data to a text file, then order can be significant. I received a gdb from ArcGIS user that hot links to photos taken on a transect through a forest. Unfortunately, the table is in random order which means that when I click next photo in the photo view (QGIS eVis), the result is that the map bounces around all over the place. eVis has filters but does not support sorting and as far as I know, QGIS attribute tables can't be ordered in the way the record order can be saved for ms-access tables. To cure this issue, I attempted to use Manifold to create a new table where records were in photoSort order. That is my test use case.
As Tim once said, "that's a lot to unpack."
If you have larger data then you shouldn't be keeping it in a text file. Do you want a human readable text report? OK. That's what report writing software is for. A good report writer will enable you to provide reports that are sorted on attributes. If you need some custom output from Manifold, that's easy to do with a script.
I received a gdb from ArcGIS user that hot links to photos taken on a transect through a forest.
It points are intended to be in some order, the usual case is that the author of the data provides a field in which some number gives the order. Usually, if that is the essence of the matter the author of the data is not going to leave something so essential to chance. For example, if a 43 sites must be visited in some specific order, a Site field might have an integer number from 1 to 43 that indicates their order. Makes sense, right?
Want to see a table in that defined order in Manifold? No problem. Ctrl-click on the Sites column header and, like magic, the table is sorted by that field.
If the software you use to browse photos cannot browse them in some order set by a field, that's unfortunate, but that's something to take up with the authors of that software.
One reason I like the idea of bringing data into Manifold as one-photo-per-record or one-binary-blob-per-record for things like audio files or videos (a suggestion I keep resubmitting...) is that once you have the data in Manifold it's easy to order it however you like, to arrange add-ins and scripts that can leverage that and so on.
But in such situations the solution is not to dumb down the database storage engine so that a side effect if it being primitive allows hacks to work that depend upon fixed order. The right solution is to leverage the power of the database in applications that depend upon sequence, for example, building GUI output choices like what photo pops up next based upon a query which orders data in the desired way using ORDER BY.
the record order can be saved for ms-access tables.
Access is a classic example of a seriously primitive database engine where the primitiveness of it sometimes has some useful side effects, so long as you are willing to live within the limits of the thing. But in such cases, well, sure it can be convenient to leverage a side effect of that primitiveness, such as tables physically storing records in a given order,.... right up until that moment when it is not convenient. Why is Access so limited in so many things and why is it unable to keep up even with the requirements of even very old applications like Outlook? Because the limitations of such primitive architecture very rapidly pile up into truly serious roadblocks.
To cure this issue, I attempted to use Manifold to create a new table where records were in photoSort order. That is my test use case.
It is not a "test case" if it is based on operating the package incorrectly. The very first topic on tables in the Basics chapter, Tables says in absolutely clear terms that tables do not have order. Setting up a test case that requires table to have order doesn't test anything about the software, it just demonstrates that failing to RTFM causes problems.
If your objective is to create some special data in a special form with Manifold, OK, that may be your use case. No problem. But you have to get there by working the software correctly, and specialty requirements may require the skills to leverage more sophisticated parts of the system, such as scripts.
If you want the software to do different things than what it does, that is perfectly OK and something to express. That's why there is a Suggestions process. There is absolutely nothing wrong and there is everything right with the notion that people might want the package to do something additional or to do things in a different way.
Experience shows that one of the best ways to accomplish that (not the only way, but one of the best ways) is to stand, as Newton put it, on the shoulders of giants when offering suggestions. You can see further and get a better view of the lay of the land standing on the shoulder of a giant. Those giants would be the many, many people who came before you in terms of offering their own insights and suggestions. In the case of something like 9, that includes the phenomenally powerful ideas evolved by very many people working over very many years with DBMS.
To take advantage of that, it is best to learn how to work the product first, and then only second offer suggestions where something doesn't make sense. It helps, of course, to get tips and insights from beginners on how to introduce the software to beginners, but that only goes so far. It is very rare that a beginner who doesn't understand how to work the software correctly stumbles onto a suggestion that has "legs," that is, has staying power and enduring value to people who know what they are doing with the thing.
It also helps to be able to take advantage of the full power of what is already there if you try to solve some interoperability problem. You might think "OK, sure, I get it why DBMS does what it does and why all this makes sense within Manifold. My problem is I need to use this brain-dead software over here which uses text files that must be in a particular order... I need to figure out how to write them out from Manifold."
The classic solution for such things is a) use a third party package that is a report writer and which can accept data in sensible formats, or b) write a script in Manifold to generate what you want. If you think such a thing could be a reasonable built-in that others might care about more than other priorities, by all means, write it up and send it it. Could be just a one-click or menu choice for a type of export.
I should add that the error message returned by Manifold ("invalid object reference") when I try to run a query that looks like a valid query does not help me one bit.
100% agree. Unfortunately, the reality is that coming up with a system which can sensibly explain what error has been made, and do that accurately, especially in situations where multiple errors are typically being made at the same time by people who have not yet learned SQL, is in many ways more difficult than writing a better query engine.
For now, it seems to make more sense to put a stronger focus on ensuring the query engine is totally reliable - never fails, never makes an error - and that it is totally articulated with a full set of big-time DBMS capabilities so it can keep up with connections to big-time DBMS systems and can support the demands of big-time GIS. A focus on error messages should be, first, on helping people who know what they are doing to find and fix simple mechanical errors such as typos, missing parens and so on. It's something Manifold will do.