So I have done all my work in several Manifold projects in 8, but I have had a license to 9 for awhile now. I am looking into transitioning those projects to the new version, but there are several issues that need to be solved.

One is when opening a project in 9, I go to file import and choose the Manifold 8 project. It comes in, but then if I try to open the map document from before it says "Cannot parse query." Any idea why this may be happening and how to fix it?

Additionally, there are many add-ins we use to make our lives easier. Do these need to be changed at all for implementation into the new system? I recall seeing something in the past that made me think this was necessary.

there are several issues that need to be solved

Actually only one.

Ahem... well, I think he means the only issue is visiting this page and beginning with Read Me First.

9 is a totally different product than 8. You have to learn to use 9, just like any other very big, very sophisticated product (Oracle, Photoshop, Visual Studio, etc,..).

That is not hard to do if you learn 9 using the advice and resources that are there to help you learn. It is exponentially harder to learn 9 if you ignore the advice and try to learn 9 by analogy to something different, like 8 or ArcGIS Pro.

Here's how to learn 9 efficiently:

1. Visit this pageand begin with Read Me First. Actually read topics. Don't just skim.

2. Read all of the topics from Read Me First all the way to the end of the Basics book. That will take most people a day or two.

3. Mix in watching videos, like the tutorial videos, and working through Examples. Do all the Examples in the Introductory Examples, and try to do as many of the others as possible.

4. 9 does have many features to help transition from 8, for example, the automatic loading and conversion of 8 components to 9 equivalents. But that doesn't cover all the (big) differences between the two systems. For things like queries, you'll have to learn SQL in 9 so you can convert 8 queries to 9.

Just like all SQLs are similar to each other but different in certain details, SQL in 9 is similar to, but different from, 8. For example, the various spatial functions are different enough so that you'll have to adapt 8 queries to 9. None of that is difficult once you learn the basics of SQL in 9, which can be learned very quickly.

@tjhb Just doesn't get any more helpful than that response. Hope you didn't hurt yourself coming up with it.

Thank you, Dimitri. I will get started with those manuals and work my forward. I was under the impression they were more compatible from the get go, but I see that is not the case. I appreciate your help.

the only one is you i think

It is like RTFM .....funny

@tjhb fire me in one post ... read and try do things before wait for help in post ....

Additionally, there are many add-ins we use to make our lives easier.

Forgot to mention... those will have to be re-done. There is API documentation for 9 here.

I do feel slightly bad about my original terse comment in this thread, which I agree was not very helpful.

I wonder if it would be worth stating the (to some) obvious facts, right in that Getting Started topic.

Along the lines that "Manifold 9 builds on the groundwork of Manifold 8 and prior Manifold versions, but it is a completely new product, far beyond incremental improvement. While all data from Manifold 8 is freely usable in Manifold 9, customizations for version 8 (including scripts and queries) must be substantially rewritten for version 9. A corollary is that compared to equivalent customizations for Manifold 8, code optimized for version 9 will often perform faster by at least one order of magnitude (occasionally two)."

I'm no good at marketing and that is probably far too negative!

All I mean is that I don't think, after all, that there is an obvious heads-up about this in the first place where we expect new users to look. (It's been made obvious on the forum many times, but AFAIK not in the manual. I might be wrong.)

That's a great suggestion and I've written it up, albeit in a "leave no stone unturned" frame of mind (surprisingly few people refer to documentation...). But what the heck, if there's a chance of helping some people, better to include a heads up.

I vaguely remember a recent thread discussing differences between 8 and 9 that affect migration, but I cannot find it for the moment, so here's a very short and incomplete, but perhaps still useful overview:

* A lot of the ideology is the same: there are components, they can be stored in a single MAP file, there are selections and transforms, the UI has multiple windows / panes / toolbars, etc. But there are a lot of differences too: you can link data in every format which you can import, all components use tables to store their data, transforms generate SQL code, the multiple windows are tabbed, there's only one toolbar and most commands are moved into panes / dropdown menus, etc. Watch the videos / read Help topics to see what is still the same vs what is different.

* SQL code for 8 will not work in 9 out of the box, it has to be adjusted. First off, the function names and parameters are different, 9 plain has more of them and they do more. Things like Surface Evaluator which were separate tools in 8 are now part of the SQL engine in 9. Same for geocoding and a lot of other things. 9 also has many different constructs which were not present in 8 - multi-statement queries, user-defined SQL functions, values, clauses for parallel computations, means to run parts of a query on a remote database, etc.

* Script code for 8 will not work in 9 out of the box either, it has to be adjusted, too. The differences are even bigger than with SQL because the object model is a lot different: it concentrates on working with databases / tables / queries / records, leaving higher-level things like transforms to SQL. SQL and scripts make for a powerful combo in 9, you can write a script function and call it from a query plus, obviously, you can call a query from a script as well, but scripts end up being different from what they were in 8. Add-ins are scripts, so all of this applies to them as well.

It is perhaps worth mentioning that you can use 8 and 9 together, at least in the beginning. 9 will read MAP files created by 8, and 8 can access data managed by 9 through 9's ODBC driver (8 connects to 9 via ODBC, 9 reads data from its MAP file or perhaps connects to a different data source, both options are there). 9 will also read Enterprise storages created by 8 if you have those, plus 9 obviously will work with any tables created / used by 8 that are stored on databases. The important thing to watch for when using 8 and 9 together is MAP files: a MAP file saved from 9 will not be readable in 8, so it is better to keep these MAP files separate (maybe name them 'data-8.map' / 'data-9.map').

Hope this helps somewhat.

For what it's worth I use them in tandem.

1. I need M8 cartographic capabilties for the moment. I really like the direction in which M9 is going but for the moment, being able to create final maps quickly is important to me.

2. the size of the datasets that I typically use is not so large so performance from 8 is more than adequate. M8 is still the most stable GIS software I use.

3. M9 is ridiculously fast with larger datasets so I normally gauge if it is to my advantage to import the data onto M9, run the required process and export to M8 to finish some details.

How soon?

That's an excellent explanation. Another thought is to articulate what is in 8 that is missing in 9, especially the ones that are common to GIS. it would safe frustration and create good will although I get why it is typically not done. Whatever is on that list would need to be updated frequently since it is getting smaller fast and many are listed on the short-term plans shared by Adam.

Here's what comes to mind: registration, labeling niceties, vector editing niceties, dynamic legends, web mapping, GPS connection, and the neat color dialogue. There are workarounds for scale bars, north arrows, and the Make Image tool. There is also a long list of what is in 9 and not in 8.

and the neat color dialogue.

Missed this... what's the neat color dialogue in 8?

http://www.georeference.org/doc/manifold.htm#displaying_data_in_a_gradient_map.htm

a Manifold gold nugget :-)

surprisingly few people refer to documentation...

The manuals are really hard to navigate. If you don't know the Manifold word usage, as opposed to other GIS terminology, then you are relegated to guessing. Chances are good you will guess a very commonly used word and receive a string of hits in a horizontal listing which vanishes behind the content window. Furthermore, there's no way to know which one of the hits you are viewing. When you get 20+ hits it can be very frustrating to hit the same numbers you just looked at (twice) just to get to the next numbered hit. Secondly, using Mike's example above, if I start on the manual's website page and use the letter indexing, the only reference to gradient is not the one he referenced. But if I use the site search ability in Google Search, the example above looks like this in the searchbar...http://www.georeference.org/doc/manifold.htm#:"gradient map" The first hit is the topic. Rather than having your own navigation, it might be better/easier to integrate the search with Google and default to their results.

Also in your interest in leaving no stones unturned, the manual is huge. It's War and Peace unabridged and expanded to 20 volumes.

And coincidentally, thanks Mike, for that exact gold nugget example. It's been 11 years since I made a heat map and I had forgotten the basics.

If you don't know the Manifold word usage, as opposed to other GIS terminology, then you are relegated to guessing.

That's true of any high end system. If you don't know Photoshop word usage, then also you end up with a lot of guessing.

Manifold deals with that the same way all high end systems do: there are introductory topics which cover all that.

If you read those, you'll learn the basics and can build from there more efficiently. If you skip the basics, you end up with unnecessary frustration. Not learning the basic terminology right at the beginning is a big oversight.

Quite right.

If you hadn't already been exposed to ESRI terminology, you would think that "symbology" would be the academic study of symbols--using the English word-formation principles from Greek that you had learnt throughout life. Like etymology, semiology, phonology, zoology, theology, entymology... The pattern is eternally set.

But instead it turns out ESRI's "symbology" involves no study, has nothing to do with Greek. It just means formatting or style.

Manifold puts considerable thought into what it names things. Good on it. Words and names matter a lot.

Just wanted to add methodology to your list. Near as I can tell that word originated at Stanford University in the early 1970s. Methodology means method in every usage I've seen.

I had ever noticed that! But you are dead right. I will remember to be grumpy about that one too now.

But instead it turns out ESRI's "symbology" involves no study, has nothing to do with Greek. It just means formatting or style.

Manifold puts considerable thought into what it names things.

Uhmmm, Manifold uses Symbology in the user manual under area styles.

But that's basically the same as thematic formatting in the Style dialog, but with fewer options, true?

Argh. Sorry, I blindly copied the wrong URL. I was trying to refer to the tool that colors areas so no adjacent areas have the same color using a minimal number of colors.

Attachments:
Capture.PNG

Point taken. We'll get to network analysis too, eventually. There are various new algorithms that were never in 8 that we'd like to add as well.