Okay, I'm finally getting around to playing with the AMV group property in dictionary items. Pathetic since I was one of those who requested this feature.

Anyway, when I add an AMV group definition does Table Builder create/maintain a "G" type (group) record in the dictionary? When I added an AMV group no dictionary group record was created. Also there is no provision to edit "G" type records in the table builder, I need to use either the editor or go back to ARev to do this.

Is there an environment or config setting somewhere that I need to change/add?

In Arev, a G-type dictionary record type was merely a portion of a SELECT or LIST statement. It didn't imply anything about multi-valued grouping.

Regards,

Dave

It does in UniVerse / Prime Information.

LIST in UniVerse will create group blocks on the output page, stacking them vertically if need be to fit on a page.

Even brain-dead entry utilities like ENTRO/ENTROC would create the AMVs for entry based on the group records so you didn't have to go back and specify what should be grouped together every time you built an entry process. Sort of what you can do in RDesign.

BTW: Groups are still supported in S/List - O/List. Banded Report Writer will show group dictionary items and allow you to add them but gives a runtime error if you try to run/print the report.

My XML exporter using MSXML to build the structures will be using groups and/or the new dictionary fields to determine AMVs. Importing will use a similar scheme, just a bit trickier to pull off.

Ideally in form designer or any of the report tools I could select a group or AMV master. From a group record the columns in the edittable or report would be in the order they in the group record. A quick check against the first dictionary item in the group would determine if it is an AMV or not.

Yes!!! And along those same lines of thought…

Edit tables (I would think) were basically designed for multivalued fields. Each edit table would be for each associated group of multivalued fields.

Or another thought…

If you had a table that hept track of GL accounting codes and their associated GL balances, and also kept track of ohhhh payment dates and their associated payment amounts. You would want one edit table for the GL accounting codes and their associated GL balances, and a seperate edit table for the payment dates and their associated payment amounts.

More of the same when it comes to reports. You would want associated items grouped so that the multivalues align.

Or if you have an generic editor for tables. It is appropiate to have associated multivalued fields.

View this thread on the Works forum...