Extend a record in an array

[Stephen T.]

I thought I'd done this before, but I can't find the code (or my recollection is wrong).

What I have is a set of database tables that I want to maintain as a structure. In the form I have various arrays for the master/detail relationships. I would then like to be able to add/delete/update rows at the child level. OK so far.

What I want to then do is have a child array defined along the lines of:
TYPE   t_extHdr                    RECORD
        rec                         RECORD LIKE srceChngeHdr.*,
        deleted                     INTEGER
        END RECORD

DEFINE m_hdrArr                    DYNAMIC ARRAY  OF  t_extHdr

...

To then be able to do:
DISPLAY ARRAY m_hdrArr TO hdrArr.*....

IE to extend the child table temporarily with a flag. I want to mark the rows the user has potentially deleted.

I can define the structure 'child_array' ok, but the DISPLAY ARRAY comes up with a 1109 (list and record field counts differ). I thought maybe before I had TYPE'd my own structure and defined the ARRAY via the type, but I'm getting the same issue going that way.

Am trying something that is possible, and if so what am I missing?

Thanks in advance.

Steve

[Reuben B.]

Stephen,

The 1109 error means that the number of fields in the screen record are different than the number defined in the form.  So in your example, ask yourself does the runner consider m_hdrArr to have two "fields", rec and deleted, or the number of columns in srceChangeHdr+1?

You probably get what you want by not using .* in the TYPE definition and/or PHANTOM

Reuben

[Stephen T.]

Reuben,
I wasn't aware that you could define a record without using the .* notation.

I do not want phantom fields - I am after a 'quick' way of defining a record like a table but with an additional field (or two). I didn't want to hand code all the table fields as that potentially causes issues on table change. As I thought I had done this before, I thought maybe 'typing' it allowed a record in a record - and to extend the record that way. But that presumably  gives m_hdrArr.rec.blah and m_hdrArr.deleted - which is then causing the RT issue.

If it's not possible (ie a record plus additional field(s) in a record), then I'll look at doing it some other way.

[Stephen T.]

...I removed the .* notation from the rec definition and it threw a compiler error...

[Sebastien F.]

Hello Stephen,
For now you need to explode the table definition by listing each field individually and use PHANTOM fields in you form, for the fields that you don't use in the form layout.
But your request makes sens, so we have added a comment for this need in a existing ticket: FGL-3267
This ticket is about extending program variable to dialog / form field bindings.
Seb

[Stephen T.]

Seb,
I was convinced that I'd done it before - obviously not.

Can I then ask that there's an option to extend the 'record in a record' without an extra 'layer'? IE currently the TYPE (and presumably DEFINE) statements take:
TYPE m_hdrRec            RECORD
         rec                       RECORD LIKE blah.*,
         someOtherFields ....
         END RECORD

...and create a two tier definition - m_hdrRec.rec.blah and m_hdrRec.someOtherField. Would it be possible to optionally extend the 'rec' definition directly under the m_hdrRec?

Steve

[Sebastien F.]

Steve,
That sounds tricky to me...
I would prefer to let you define structured arrays like you do, nicely grouping field in sub-records, and has us extend the bindings in dialogs to link any array record/sub-record member to the form field of your choice, as you can do with a simple INPUT variable-list FROM field-list dialog.
Seb

[Rene S.]

Hello,
see this definition:

Code (#) Select Expand


    DEFINE states ARRAY[100] OF RECORD
        state RECORD LIKE state.*,
        extra1 INTEGER
    END RECORD


It's possible to use nested records in DISPLAY BY NAME, DISPLAY TO, INPUT BY NAME, INPUT FROM.
It's not possible to used tested records in {DISPLAY | INPUT} ARRAY. The Informix compiler throws an error at esql level, Genero throws an runtime error.

I consider the support of nested records in DISPLAY or INPUT ARRAY as a useful enhancement.
Rene

[Stephen T.]

Steve,
That sounds tricky to me...
I would prefer to let you define structured arrays like you do, nicely grouping field in sub-records, and has us extend the bindings in dialogs to link any array record/sub-record member to the form field of your choice, as you can do with a simple INPUT variable-list FROM field-list dialog.
Seb

Seb,
Would it not be possible to have a way of building a record using a record?
Something like:

TYPE t_extHdr                            RECORD EXTENDS LIKE hdr.*,
         deleted                               INTEGER
         END RECORD

or
TYPE t_extHdr                            RECORD
         deleted                               INTEGER,
                                                    EXTENDS LIKE hdr.*
          END RECORD

EXTENDS or INHERITS...or some other term that implies the same?

[Sebastien F.]

Got it now, yep this looks good to me, will add it to the ticket and will be discussed internally.
Seb

[Stephen T.]

Seb,
I thin k it may impact other things though Seb.
Moving data around is 'easier' the 'old' way:

DEFINE m_hdr                                   RECORD LIKE hdr.*

TYPE t_extHdr                                   RECORD
        rec                                             RECORD LIKE hdr.*,
        deleted                                      INTEGER
        END RECORD

DEFINE m_hdrArr                              DYNAMIC ARRAY OF t_extHdr
...allows you to:

LET m_hdrArr[1].rec.*                        = m_hdr.*


...which keeps it 'clean' - otherwise it seems that it gets into using THRU notation when moving data around - something like:
LET m_hdrArr[1].*                              = m_hdr.*,0
and
LET m_hdr.*                                       = m_hdrArr[1].firstField THRU m_hdrArr[1].lastRec

..(and does that work on LET?) - which then poses the same maintainability issues - and I don't think anyone would want a LET CORRESPONDING to appear like in old COBOL...

Sorry to have been a pain - and maybe the simplest way is for me just to set up pseudo records in the database and handle it that way

[Sebastien F.]

Yes. Just discussed internally, we agree the initial request (being able to bind structured arrays in DISPLAY ARRAY / INPUT ARRAY) is the best solution compared to the EXTEND LIKE idea.
Seb

[Michael L.]

Binding support for nested/structured RECORDs within INPUT/DISPLAY ARRAY is also important to us for screens with a master/detail/detail relationship, where we have a detail table dependent on another detail table.

Currently without binding support for structured RECORDs, we need to take care of the deletion/appending manually on APPEND/DELETE actions to keep the two detail tables in sync.

With structured RECORDs, the relationship is inherit so deleting/appending rows will automatically take care of the dependent detail table.
The DIALOG/INPUT code would be simpler and protect the program from future problems.

---

(Idea) Maybe we should be able to specify the columns for an INPUT/DISPLAY ARRAY without having to specify the whole RECORD (.*).
It would make the master/detail/detail even easier, because you could have something like:

DEFINE rec DYNAMIC ARRAY OF RECORD
                field_1 STRING,
                field_2 STRING,
                depend_rec DYNAMIC ARRAY RECORD
                    dep_field_1 STRING,
                    dep_field_2 STRING
                END RECORD,
            END RECORD

DIALOG ATTRIBUTES(...)

    -- MASTER/HEADER
    INPUT ...
    END INPUT

    -- DETAIL
    INPUT ARRAY rec.field_1, rec.field_2 FROM s_rec.field_1, s_rec.field_2
        ...
    END INPUT

    -- DETAIL (DEPENDENT)
    INPUT ARRAY rec[DIALOG.getCurrentRow("s_rec")].depend_rec.* FROM s_depend_rec.*
        ...
    END INPUT

    ...

END DIALOG

... That's probably taking it a bit far but it would allow the developer to completely avoid manually handling the logic around the dependent detail table, temp dynamic records, TEMP DB tables, etc.

[Stephen T.]

I would also like the ability to input directly into a multi-dimension array, if possible. In the example shown in my postings recently, I have a header with child versions and then the versions can have other lists (in this case directories and change details). The code holds most of the stuff in arrays dim'd by the version, but I can't then input into that versions 'directories' or 'change details' directly and have to copy out of (and then back into) the multi dim'd array into a single dimension  'input/display array'. I think that was raised way back in the dim and distant past.

[Reuben B.]

I would also like the ability to input directly into a multi-dimension array, if possible. In the example shown in my postings recently, I have a header with child versions and then the versions can have other lists (in this case directories and change details). The code holds most of the stuff in arrays dim'd by the version, but I can't then input into that versions 'directories' or 'change details' directly and have to copy out of (and then back into) the multi dim'd array into a single dimension  'input/display array'. I think that was raised way back in the dim and distant past.

... ask your support consultant to get yourself added to FGL-3324.  The classic example is for retail environments, where you have a variable number of attributes across the top e.g. size, and a variable number of attributes down the left hand side e.g. colour, and you want a DISPLAY ARRAY to display quantities of the various combinations and/or select a combination, or when ordering an INPUT ARRAY to allow you to enter the various quantities of each combination. 

Won't be in 3.0 but hopefully be in contention for later versions

Reuben