Subscribe to this thread
Home - General / All posts - Manifold Future Wizards
dchall8
313 post(s)
#12-Oct-17 00:11

Are wizards in the future for 9 or are we going to have to become our own SQL wizards? Here's what I'm talking about.

I need to have meaningful labels for the areas in my map. The wizards in Manifold 8 make it fairly easy to create them. Mine need to be 3 lines deep and located in the centroid of the areas on a live basis for when the areas are split into pieces. In 8 with a couple of clicks I can change the font color using the labels toolbar. And I only want to see the labels when the area is selected. In Manifold Future it looks like the labels are currently limited to one line, font cannot be formatted, and locating them at the centroid is a separate process requiring a redrawing of centroids with every area split. And I can't find a way to add a field with a Boolean switch for selectedness.

But before I can do any labels I have to have the correct information in the table fields. When I opened the 8 map file the fields on the related table did not come through. So now I need to figure out how to relate the area table with the data table. Again, the wizard in 8 makes it easy to relate the table to the drawing.

One of the fields in my labels is acreage. I did figure out how to make a new field for area and how to make an active field converting area to acres. For me this was a wildly satisfying achievement. Now how do I round the decimal places down to 3? I'm looking at RoundDecs(<value>,<decimals>):<value>. I tried RoundDecs([WorkingParcels Table].[Acreage],3):Temp, but it did not like my Invalid object reference. I'm not certain what part of that is invalid, but I am frustrated enough to write and ask.

Also in 8 it is easy to update the calculated fields in the table. I don't see how to update it in Future.

Is there a way to save queries to the Project pane?

How can I reuse queries from Manifold 8? They need to link to a table.

rk
198 post(s)
#12-Oct-17 05:41

Call the fn like this.

RoundDecs([WorkingParcels Table].[Acreage],3)

The thing after colon indicates return type of the fn, not part of fn call syntax.

dchall8
313 post(s)
#12-Oct-17 14:14

Invalid object reference again.

Dimitri


4,193 post(s)
#12-Oct-17 15:00

Invalid object reference again.

Way too much information. From the above it's not possible to respond with anything but "You are doing something wrong again." It would be more productive to be able to state precisely what is being done wrong and how it should be corrected.

If you want people here to help you find the errors you are making, you have to tell them every last detail of what you do, such as the *entire* text of your query, along with a complete schema for every table involved. That's required to find things like spelling errors in field names, incorrect syntax that leads to referring to things that don't exist, etc.

I would also strongly, firmly urge you to take the advice that, I believe, has been offered many times in this forum: choose a transform template that is similar to what you want (see, for example Round to Decimals in the Transform Templates - Numeric topic) and press the danged Edit Query button to see a fully complete SQL example of how to use a particular function of interest. After you read that example and understand it perfectly, perhaps by making a few changes to it to see what those do, then go and write your own queries from the ground up.

After all, if you have a wizard ready to write SQL for you, why not use it? :-)

dchall8
313 post(s)
#12-Oct-17 19:10

Here's the entire text of the query...

RoundDecs([WorkingParcels Table].[Acreage],3)

Schema is attached. Is there supposed to be more to it? I do have a query from 8 to reformat several columns in one pass. I'll look at that to see if I can make it work in Future. No need to continue down this path until I've dug deeper into it.

In Manifold 8, as you know, you can right click on the field heading and format just about everything about how the numbers look in the table. I usually set to decimals showing 3 decimal places, default negatives, separate thousands, and right align. Then when I have the ViewBots showing with total acreage, the ViewBot sums all the computed acreages and compares to the acreages in our appraisal system to find large discrepancies.

I do recall seeing something about how the templates write code. I was not a Radian owner until this week, so there's a lot I've overlooked or not been able to try until now. I have a feeling I'm going to spend the afternoon clicking on the danged Edit Query buttons to learn how they work. Ground up probably means something different to me than what you intend. I'm thinking hamburger...which is how I feel after trying to get SQL to work. But I am willing to learn, so here goes.

Attachments:
Schema.jpg

Dimitri


4,193 post(s)
#12-Oct-17 20:36

Is there supposed to be more to it?

Yes. A function by itself is not a query. You don't need much more but you do need some. See what the edit query button does for the analogous transform template and you'll see what I mean.

I strongly recommend you get a copy of one of Chris Fehily's first rate books on SQL and cruise through it. SQL is not the least bit hard but you do have to honor what few demands it makes in terms of observing syntax. Chris is a great writer and has a knack for explaining SQL clearly and practically in the shortest way. He'll have you up and running in no time, with you thinking at the end, "wow, that was way easier than I thought..."

Note that you can use features in the Command Window to evaluate expressions without writing full SQL. It's a very useful feature, but there too you have to honor the syntax, like using the ? command to evaluate an expression. The SQL Functions topic uses that to show short snippets of examples without writing full queries.

Likewise, the transform dialog's Expression tab allows you to get away with writing expressions that are not full SQL queries, because the Expression tab helpfully surrounds them with necessary infrastructure. But don't confuse such short cuts with writing a real query.

By the way, one reason full info is necessary is because it is easy to overlook something simple, like a typo.

In Manifold 8, as you know, you can right click on the field heading and format just about everything about how the numbers look in the table. I usually set to decimals showing 3 decimal places, default negatives, separate thousands, and right align. Then when I have the ViewBots

More formatting for tables will get added as we cycle through formatting for tables. I love ViewBots too. I'd like something analogous to them to be in 9 as well.

Dimitri


4,193 post(s)
#12-Oct-17 14:48

A lot to discuss here...

Are wizards in the future for 9 or are we going to have to become our own SQL wizards?

There are very many wizards already there, in the form of transform templates where you can click the "edit query" button to have it write SQL for you (very wizardly...).

If you prefer something more free-form than the SQL the system writes for a template, use the query builder.

I need to have meaningful labels for the areas in my map.

Labels are still at Radian level, not where they are going. Keep your finger on the pulse of changes with Future. As formatting adds labels there will be far, far more capabilities with labels.

I have to have the correct information in the table fields. When I opened the 8 map file the fields on the related table did not come through. So now I need to figure out how to relate the area table with the data table. Again, the wizard in 8 makes it easy to relate the table to the drawing.

I don't quite follow the above but in general Radian / Future / 9 has far more capabilities than 8. There is no such thing, by the way, as an "area table" that is different from a "data table," so I don't understand what you mean by that. Everything is a table. A drawing is a viewport into a table. If there are any fields you can work with in a query using a drawing's name, those fields are in that drawing's table.

Also in 8 it is easy to update the calculated fields in the table. I don't see how to update it in Future.

Future automatically updates computed fields. I note that "calculated field" is not Manifold terminology. The right term is "computed field." Use the precise terminology so you can follow along with examples and report exactly what you've done in the forum.

You can add a field that has set field values, and you can do something related, but different, which is to add a computed field. There are two examples that show the difference:

Add a field to a table and fill it

Add a computed field to a table

If you just added a field to a table and filled it, but did not create a computed field, well, there is nothing to update because you've just filled that field with static values, not computed values. It's an ordinary field and will have white background. If you created a computed field as set forth in the second topic above the field will have a light gray background because it is not editable... the values in there are computed based upon some expression.

Is there a way to save queries to the Project pane?

Queries you create in the project pane are automatically saved. See the "to create a query" list of instructions at the very top of the Queries topic.

Do you mean, is there a way to save a temporary query that I wrote in the Command window into a query component in the project pane? Yes, of course:

Copy the query text. Create a new query in the project pane using whatever name you like. Open that query and paste the query text into that query. Done. As noted in the Queries topic changes made to query components are automatically saved.

As advised in the Queries topic, the usual way to create a new query is to create a new query in the project pane, to open the query and then to go forth and write whatever SQL you want in that query. But if you didn't do that but instead just launched the Command Window in an ad hoc way, no problem. Copy whatever SQL you've written and paste it into a query component.

How can I reuse queries from Manifold 8? They need to link to a table.

Open the query text and re-write it for Radian SQL. Depending on the query that can be trivial or it can be significant.

They need to link to a table.

Not sure what you mean by the above, as queries are operations on tables, so they all link to a table. Could you describe with more detail what you had in mind?

dchall8
313 post(s)
#12-Oct-17 23:54

Thank you for the reply. As for wizards, I prefer something where the options are already built into a dialog box, a la Manifold 8. For example if I want to format the text or numbers in a field, I can right-click the field name, select Format from a context menu, and make a few selections in a dialog box type of wizard. Other wizardly methods in Manifold 8 need no dialog box. If I want to sort a table based on a field I can click or shift-click on the field name. If I want to rotate a mapped object I can select the object and use the tools at the bottom of the window to rotate. If I want to number 5,000 parcels by a factor of 3, from south to north, it's only a few clicks. So I guess my question is will Future have dialog box or the intuitive types of transforms? If I have to program my own wizards, I'll likely stick with version 8. It's not as fast as Future, but it does what I need with no big learning curve.

On my other question, I lost you in the same place two times - must have been my wording. In Manifold 8 I use the Table Menu > Relations to connect two tables using a key field. One of these tables is my map parcel drawing table; the other is information table from our office computer. The map parcels table holds the geometry, a property identification code number (PID), and three other fields I have created. Two are scribble space for use on the fly. The other one is a computed acreage field. All the important information about the parcels comes from our office database. Once a week I query the office database to get a subset of data needed for the maps. I take that data through Excel to a .xls file. Then import the .xls to 32-bit Manifold, copy, and finally paste into 64-bit Manifold. Then I "relate" that table to my parcel map using PID as the key. This last step is what I'm trying to do here. I understand 'relate' as it applies in Manifold 8, but I don't see a template for it in Future.

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.