4 Replies Latest reply on May 30, 2012 10:35 AM by Marty1

    Storing found data



      Storing found data



      I wish to temporarily store some fields from found records so that I can sort / print and use then in other ways. I wish to store them in a separate table called 'Hold'. This sequence operation is to find all the people with recorded birthdates. I have 3 tables, in the same database, 'Contacts', 'Partner' & 'Child'. Each table has a field DOB, Name & primary/foreign keys. I would like to find all the entries in each of the tables with a "valid" birth date {Card_Bday = "Yes"), and store certain fields of each record in another holding table. Prior to accessing the 'Hold' table it will be emptied (all date deleted). Say the fields to be stored were 'name', 'dob' & 'kf_address'

      I was thinking to run a script similar to this to find all the contacts with a "Yes" in the birthday card field, then write the 3 required fields to the 'Holder' table. Although this script does not write and field information !!

      I then wish to run the same process for the remaining tables 'Partner' & 'Child', and to have these details added to the 'Holder' table, not overwritten.

      I should then have a complete list with all contacts that require cards. I can perform other date calculation & searches accordingly.

      I hope you can assist... Have a good day







        • 1. Re: Storing found data

          Since your layout is based on Contacts, Set Field [Holder::Field ; Contacts::Field ] will only work if a record already exists in Holder linked via a valid relationship to the current record in contacts.

          This code would copy the data from one field in contacts to a designated field in a new record in Holder:

          Set Variable [$Name ; value: Contacts::name_first]
          Go to Layout [Holder ; (Holder)]
          New Record/Request
          Set Field [Holder::name ; $Name]

          But why loop through your records like this when you can just perform a find for all records in contacts where Card_bDay = "yes"?

          And why have this data in three separate tables when you can combine the data into a single table with a "type" field to identify each record as a "contact" ; "partner" or "child"?

          And if the records were combined in a single table  pulled up with a single find for Card_bDay = "yes", your report layout can then be based on the contacts table and you don't need to copy any data to the holder table in order to get your report.

          • 2. Re: Storing found data

            Thanks, all very valid comments and understood. I did originally have all as suggested in a single table, detailed as   contact::name, contact::partner, contact::child  the sorting worked perfect as recommended.

            However, I was having a problem to show the records in an easy form, with the headings

            DOB           Name                Address

            The problem was the 'name' column..  as I had the actual name held in 3 differently named fields; but possibly your comment about using the  "type" field could solve this, I can easily revert back. Please can you elaborate on the "type" concept.

            Many thanks in advance


            • 3. Re: Storing found data

              You can set up a field to identify the type of contact record. Using Manage | value lists, a value list can be set up with the values "contact", "Partner" and "Chlid". You can then format the type field as a pop up menu, drop down list, radio buttons, or even a check box group. If you use checkboxes, you can identify the same record as being a member of more than one of these three categories.

              If you want to see only "contact" records, you can enter find mode, select "contact" in the type field and perform a find.

              You would then use just one name field (or one set of name fields such as firstname, lastname, middlename) for recording the name of all contact records regardless of type. The same would be used for DOB and address fields--though a related table of addresses so that multiple records can link to one address may be the next design improvement you can make.

              • 4. Re: Storing found data

                Great - Thanks. I have already (originally) set up a relationship for the addresses that works well, linking persons & businesses to either single or shared addresses. My issue was that within the same record I had the 3 fields contact, partner & child, as described above. Although now I will try your suggestion to have a single record for each 'person' and link them to the address table, and the other contact members by ways of 'types' and the ID keys....