dag@fciva.FRANKCAP.COM (Daniel A. Graifer) (04/02/91)
I am developing an application in Accell 1.4/Unify 4.0 and I am having a problem with one of my forms. The form is multi-occurance, and for each record key found in the target table, I need to find 5 other related record keys in the same table. Finding these records requires three double nested SET/SELECT/EXECUTING statements. The problem is that non-database screen fields are not inherently multi-valued, even if you include them in the repeating area, or set their multi-occurance attribute explicitly. Thus, each time the user changes record, the 5 other records have to be relocated. This all takes too long (about 1 second per 'master' record key). Is there some way to store the other 5 key values for each record so that I don't have to find them again every time the user hits NEXT/PREVIOUS RECORD? The only idea I've come up with is to write a set of c-hook functions to initialize, load, and query an array of tuple-numbers pointed at by some global. That's awfully kludgy. Any other ideas? Thanks in advance Dan -- Daniel A. Graifer Coastal Capital Funding Corp. Sr. Vice President, Financial Systems 7900 Westpark Dr. Suite A-130 (703)821-3244 McLean, VA 22102 uunet!fciva!dag fciva.FRANKCAP.COM!dag@uunet.uu.net
meh@ufycorp.Unify.Com (Mark Hansen) (04/02/91)
In article <593@fciva.FRANKCAP.COM> dag@fciva.UUCP (Daniel A. Graifer) writes: >I am developing an application in Accell 1.4/Unify 4.0 and I am having >a problem with one of my forms. The form is multi-occurance, and for >each record key found in the target table, I need to find 5 other related >record keys in the same table. Finding these records requires three double >nested SET/SELECT/EXECUTING statements. The problem is that non-database >screen fields are not inherently multi-valued, even if you include them in >the repeating area, or set their multi-occurance attribute explicitly. Thus, >each time the user changes record, the 5 other records have to be relocated. I sure don't understand what you mean here. If you set the MULTI-VALUED attribute of a screen field, it will be able to take one value for each record in the selected set. For example, the following: Code: SSSSSSS Desc1: SSSSSSSSSSS Desc2: SSSSSSSSSS Desc3: SSSSSSSSSS In this case, the Code is the Screen/Target field. Desc 1, 2, and 3 are Screen ( display ) field marked in the Generator as MULTI VALUED. In the ON FIND section, you do the following: SET $desc1, $desc2, $desc3 TO SELECT #desc1, #desc2, #desc3 FROM code_table WHERE code_id = $code; This wil set the value of the three description fields to those from the code_table for *this* code ( or rather - this occurance of the code in the selected set ). If your search finds 4 codes, then you should have 4 records in the selected set, each having appropriate desc1, 2, and 3 field values. As you can see, the MULTI-VALUED attribute means that the Screen field can take on one value for each record in the selected set. Do you have to store 5 values for each Screen field for each record that you find? If so, it sounds like you might need an array. I wrote an array package for Accell and will be happy to make it avaliable to you. With this package, you can define two dimentional arrays. For example, you can define an array with a structure of 5 fields, say desc1 through desc5. Now for each record you find, you can add an element to the array and fill in each member with the appropriate data from your SET/SELECTS. You can access the 4th member for the current record with something similar to the following: get_elm( "array_name", current_record_num$(), $d1, $d2, $d3, $d4, $d5 ); > >This all takes too long (about 1 second per 'master' record key). Is there >some way to store the other 5 key values for each record so that I don't >have to find them again every time the user hits NEXT/PREVIOUS RECORD? The >only idea I've come up with is to write a set of c-hook functions to >initialize, load, and query an array of tuple-numbers pointed at by some >global. That's awfully kludgy. Any other ideas? > >Thanks in advance I hope this was helpful. >Dan >-- >Daniel A. Graifer Coastal Capital Funding Corp. >Sr. Vice President, Financial Systems 7900 Westpark Dr. Suite A-130 >(703)821-3244 McLean, VA 22102 >uunet!fciva!dag fciva.FRANKCAP.COM!dag@uunet.uu.net Mark E. Hansen internet: meh@Unify.Com Manager, Client Support Services ...!{csusac,pyramid}!unify!meh Unify Corporation voice: (916) 928-6433 3901 Lennane Drive, Sacramento, CA 95834-1922 fax: (916) 928-6403
itkin@mrspoc.Transact.COM (Steven M. List) (04/03/91)
dag@fciva.FRANKCAP.COM (Daniel A. Graifer) writes:
[ about saving non-target data for each record in a multi-occurrence form ]
A technique developed by several people is to define a number of fields
that are associated with each record/row in the m-o area, each with a
window_width of 1 and any field length that is necessary. Set each of
these fields to be Multivalued. In the BEFORE FORM section, set the
WINDOW_WIDTH for these fields to 0. These fields are now invisible but
connected to each displayed record. You can store data in these fields
that will remain with the record regardless of how the user moves the
cursor.
--
+----------------------------------------------------------------------------+
: Steven List @ Transact Software, Inc. :^>~ :
: Chairman, Unify User Group of Northern California :
: itkin@Transact.COM :dag@fciva.FRANKCAP.COM (Daniel A. Graifer) (04/05/91)
I want to publicly thank Steven List and especially Mark Hansen (Manager of Unify's Client Support Group) for their assistance on this issue. Mark has exchanged a number of E-mail messages with me dealing with this questions and other related issues. I had been mislead by an earlier instructor about the behaviour of non-target multi-occurance fields. Manually marking the screen field as Multi-Occurance does what I need (provides single dimensional array capabilities). Steve's suggestion of setting the display width of such variables to zero in the Before Form section is also excellent. If you want multi-dimensional arrays, you need to impliment them using C-hooks. They inherit the usual 'c' data management problems: You have to do your own garbage collection. Again thanks to Steve, Mark and Unify Corp. for their help. Dan -- Daniel A. Graifer Coastal Capital Funding Corp. Sr. Vice President, Financial Systems 7900 Westpark Dr. Suite A-130 (703)821-3244 McLean, VA 22102 uunet!fciva!dag fciva.FRANKCAP.COM!dag@uunet.uu.net