1 2 Previous Next 15 Replies Latest reply on Dec 8, 2009 6:12 PM by DLW-BPEX

    Common One; indexed calculation field

    DLW-BPEX

      Title

      Common One; indexed calculation field

      Post

      Could someone please explain briefly how/why this technique is used, or perhaps point to some documentation? I thought I recalled reading awhile back that it ensures starting a fresh database and not having 0 records. I have seen it used in several example solutions, and I would like to understand the design rationale behind it.

       

      Thank you.

      David

        • 1. Re: Common One; indexed calculation field
          philmodjunk
             Are you asking why there are different storage/indexing options available for a calculation field?
          • 2. Re: Common One; indexed calculation field
            DLW-BPEX
              

            Hi, Phil.

            No, I don't think so. I believe I understand in general the trade-offs and reasons for choosing storage vs. indexing. But the specific technique of defining and matching Common One fields set to a value of 1 seems to be escaping me.

            It is used, for example, in SeedCode's Calendar Free solution, as well as another example I saw some time ago. I can't seem to follow just how it works.

             

            Thank you.

            David 

            • 3. Re: Common One; indexed calculation field
              philmodjunk
                 A field set to always store the value "1" is "Ye Olde Filemaker way" of setting up a relationship that matches all records in one table to all records in another. With current versions of Filemaker you can often simply use the "X" operator instead of "=" when defining the relationship to get the same result. You still need fields in both tables that are always nonblank, thus there are still cases where a "common one" field is still useful as such a field will never be empty.
              • 4. Re: Common One; indexed calculation field
                comment_1
                  

                PhilModJunk wrote:
                You still need fields in both tables that are always nonblank

                No. Actually, you don't need any fields for a x relationship - you can set it up using ANY two fields, and it will continue working even if those fields are deleted later.


                • 5. Re: Common One; indexed calculation field
                  DLW-BPEX
                     Thank you, both.
                  • 6. Re: Common One; indexed calculation field
                    philmodjunk
                       Thanks comment, as always, I appreciate your posts that further my ongoing education in all things Filemaker.
                    • 7. Re: Common One; indexed calculation field
                      DLW-BPEX
                        

                      Phil,

                      I have unmarked this as solved, even though the info both you and comment provided was very helpful.

                      From your post, it seems that my recollection was right: Common One is used to ensure that one or more fields never is empty. Yes?

                       

                      That was my original question and the one that still baffles me. I'm not clear on how that field in one or more tables accomplishes that objective. Probably just another denseness episode on my part.

                      This solution has container fields that must have content when a fresh version of the database is first launched.  

                       

                      Any guidance is appreciated. In the meantime, I'll keep staring at it until something gives.

                      Thank you.

                      David 

                      • 8. Re: Common One; indexed calculation field
                        comment_1
                          

                        DLW-BPEX wrote:
                        Common One is used to ensure that one or more fields never is empty. Yes?

                        Not really: it assigns a common value (1) to ALL records in the table - so that a relationship using this field always matches ALL records in the table.

                        • 9. Re: Common One; indexed calculation field
                          philmodjunk
                             The '1' is just a simple value that the match field stores for all records in the table. Since all the records have the same value in their match field, they'll all show up in a portal where the match field on the other side of the relationship is also '1'.
                          • 10. Re: Common One; indexed calculation field
                            DLW-BPEX
                              

                            So then is there a way to create a solution having content in container fields, such that when the final solution is cloned (no records) the container field content is retained?

                             

                            I guess that question is self-contradictory, since no records = no field contents. What I am asking is how to get a picture into a container field in an empty database, particularly under IWP which is not compatible with the Insert Picture script step.

                             

                            Perhaps storing references to images in a Web folder?

                            We use a hosting service, so putting the actual images in the proper location is something we may not have direct control over.

                             

                            Is there another way? 

                             

                             

                            And thanks again to both of you for clarifying the Common One issue. (I must have mis-remembered what I read some time back.)

                            David

                             

                            FMP10 Advanced, Mac OS X 10.4.11 and Win XP Pro 

                            • 11. Re: Common One; indexed calculation field
                              comment_1
                                 Can you explain your purpose here? A cloned file, as you say, has no field content - and AFAIK, IWP clients cannot insert images into container fields, even if there are records.
                              • 12. Re: Common One; indexed calculation field
                                philmodjunk
                                  

                                You might want to check out this thread for some ideas:

                                 

                                Importing objects

                                 

                                Alternatively, You can do a "save as clone" and then turn around and use Import Records to import data into your clone from the file from which you cloned it. This data can certainly include the contents of container fields. You can also script this to make it an automated process.

                                • 13. Re: Common One; indexed calculation field
                                  DLW-BPEX
                                    

                                  Yes. And even if the IWP user could insert images, it would not help because this really needs to be part of the interface upon launch.

                                   

                                  I am trying to create "scaleable" rounded gradient buttons. It involves placing a series of images in global container fields, then selectively calling those images (cropped and aligned appropriately) into various layout fields to get the desired size/appearance overall.

                                   

                                  An example is SeedCode's CalendarFree.

                                   

                                  Thank you.

                                  David 

                                  • 14. Re: Common One; indexed calculation field
                                    comment_1
                                      

                                     I believe your options come to this:

                                     

                                    • import the images after cloning;
                                    • keep the images in a second file;
                                    • store the images as reference only (or as a calculated path).
                                    1 2 Previous Next