7 Replies Latest reply on Feb 8, 2010 8:30 PM by drushton

    Dealing with records

    drushton

      Title

      Dealing with records

      Post

      How can I use a button to move a record from one table to another. I would like to modify the record in the second table and then move it to other tables Then be able clear the second table without changing the original record. I have built the relationships using primary unique keys. The relationship is set up to only create records in the decending (child) table. What is the best way?

       

       

                Records Source (Table) to second (Table) Revelant Records Modified, after records created in downstream records, cleared from this table to (Table0 Records Retained 

        • 1. Re: Dealing with records
          ninja
            

          Howdy drushton,

           

          I'll answer your question first, then tell you why you should ignore my answer...

           

          have the button run a script like:

           

          SetVariable [ $ID ; Value: IDkey]

          SetVariable [ $Field1 ; Value: Field1]

          ...continue for all fields 

          GoToLayout [ some layout based on RelevantRecordsTable]

          new Record/Request

          SetField [ IDkey ; $ID ]

          SetField [ Field1 ; $Field1 ]

          ...continue for all fields

           

          Cumbersome, but it works.

           

          A much better way would be to have an additional field in your ONLY table that marks the record as "Source", "Relevant Modifications" or "Retained".

           

          That way, the records won't have to move but you can sort them and find appropriate found sets.  You won't need the other tables, either.

          • 2. Re: Dealing with records
            drushton
               Thanks, Since the posting I have tried using a script with the duplicate record request from the source table to the second table trying to isolate the new record from the original then relating them to the next Table. I don't follow your suggestion on how to remove the records from the modified table while not changing that record or the original record. Am I on the right track thinking I need to recreating the record I choose in a new table ...that protects the original record and then relating it to other tables? I believe it needs to react similar to a internet shopping cart. I need to use the second records modified only as a distribution table(sort of speak) for the records table and then clear for the next list of records from the source. Appreciate your patience while I try to teach myself FMP 9 from my experience FMP2 mac.........Windows 7 or not I miss my Mac  
            • 3. Re: Dealing with records
              ninja
                

              drushton wrote:
              Thanks, Since the posting I have tried using a script with the duplicate record request from the source table to the second table trying to isolate the new record from the original then relating them to the next Table.

              "Duplicate record/request" duplicates the record into the same table, not another table. 

               That is why I had the script go to another layout (thus another table) and create a NEW record.

               

               I don't follow your suggestion on how to remove the records from the modified table while not changing that record or the original record. 

              ??? Sorry to be slow, but I don't understand what you don't understand.

               

              Am I on the right track thinking I need to recreating the record I choose in a new table YES, create a new record in the new table and set the fileds one by one....that protects the original record and then relating it to other tables? 

               

              I believe it needs to react similar to a internet shopping cart. I need to use the second records modified only as a distribution table(sort of speak) for the records table and then clear for the next list of records from the source. Appreciate your patience while I try to teach myself FMP 9 from my experience FMP2 mac.........Windows 7 or not I miss my Mac  


              Please note my suggestion at the bottom of my post.  It would be better if you kept these records all in one table rather than move them around from table to table.  Use a field to mark their status, but keep them all in one table.  Then you won't need to recreate them, move them or duplicate them...you just need to update their status.

              • 4. Re: Dealing with records
                drushton
                  

                 I don't follow your suggestion on how to remove the records from the modified table while not changing that record or the original record. 

                ??? Sorry to be slow, but I don't understand what you don't understand.

                 

                 

                I will rework the tables to keep the records in a table and not move them about..But since there will be several different users how will I be able reset the layout (removing the old user modified records) to let each user start new for there record requests. Thanks

                 

                 

                 

                • 5. Re: Dealing with records
                  ninja
                    

                  OK, got it.

                  You want the user to see records of a certain type, and not have to wade through records of other types.

                   

                  Method1: 'Casual'

                  On your opening script, perform a find for the type of record you want the user to see.  In this way, they will be working within a found set as opposed to working on a different table.

                   

                  i would additionaly suggest a button on the layout that performs this find also.  The users can hit this button anytime they want to be kept in a found set of "Records to review" or "Pending" or whatever word you use. 

                   

                  ========================== 

                   

                  Method2: 'rigorous'

                  Do the same find on startup, but additionally set the users' access privileges to not allow editing, or perhaps even not allow view, of records that meet certain criteria.

                  The criteria you would use would be the value found in the new "Status" field.

                  Perhaps the user would:

                  View when Status = "Pending" AND Status = "Modified"

                  Edit when Status = "Pending"

                   

                  The level of lock-out would depend entirely on your data flow and what you are trying to do with these records.

                  Under Accounts&Privileges, there is an option to set Record Privileges to "custom..."  You would work there if you choose to go this more rigorous route.

                   

                  Note: If you block view, you do not block the ability to bring up the record.  It is just that when the record is brought up, it would look blank.  That's why you want to work within found sets...bunches of blank records get annoying.

                   

                  Either way, you will have your users working within found sets.

                  • 6. Re: Dealing with records
                    drushton
                      

                    In the original question I referenced a table as Records Source. What this actually contains are records of machine parts. I have set up custom privileges for different levels of access. Only four people have access to input or change records, print reports etc. These are the people that actually issue the part. The people that actually need the part have view only access except on the Records Modified (parts Request) layout and can only Add personal information to the record (not modify the original record fields) on this layout. This user finds the record (part) thru a find layout that uses fields that describe that part. It is possible that the person might get a multiple find and need to choose a single part (record) from that find. This find needs to return a listing due to the lack of information the user has. It gives them a chance to find the part from the information included in the found list of records. Now I have added mechanical drawings that have a assembly view. Each part is assigned a unique (Item) number that relates it to a record. On the drawing layout I have find fields that allow the user to find one record at a time by using the unique (item) number. So each user can access all drawing and records and may need parts (records) from several different layouts before all the (records) are found. This is why I original asked about a button script to make the records from different layouts to be added to a common layout (table)This layout Records Modified (Parts Request) is the most important layout because it really is the interface between all users . It needs to have the original record found by the view only user which contains the information to find the part and after their personal information (clock# machine # Qty.) is added it is used by a different group of people to generate reports and updates fields in the original record. After each view only user is finished the layout (Parts Request) needs empty of records so the next view only user can enter their part (record) request without viewing the previous user but all updated records.

                     

                      Changed Items:  I have move the Records Modified table (Parts request layout) and the 2 Records tables (Parts issued) and (Stock out) back into the original table (Records source)

                                             I only had unique (Item) numbers for the records shown on the assembly drawings. Added a unique (Item) number for each record.

                                             Changed access privileges on view only user in a attempt to satisfy the goals in the parts request layout

                                             Removed primary keys 

                                              Added fields to parts request, parts issued, stock out to help with bringing the layouts into one table.

                                             

                                              Hopefully small step in the right direction..Thanks again

                    • 7. Re: Dealing with records
                      drushton
                        

                      After moving back into one table I added the fields (relevant modifications, retained) as you suggested and brought them up in the layouts, Parts requested and Parts issued. To add data to the field I used a pop up menu (x) or no entry. I thought this would distinguish records. If different users with the same level of access use the same layout to add their information how do I make it work as I mentioned in my last reply? I would like for the common layout to refresh between users. Using the new fields I am trying to perform a find to locate the records I need to use...Right? Please help Thanks