1 2 Previous Next 15 Replies Latest reply on Dec 13, 2011 5:43 AM by Todd Geist

    Where do you store your version number(s)?

    KylePutzier

      I usually create multi-file databases. Each file may have many tables that are usually associated to each other. I dont expect this approach to be uncommon. I need a better way of keeping track of which version the file (or database as a whole) is at.

      I was thinking of making a table in each file whereas each record contains the version number, at that time, and other info such as date, changes made, etc. of that version.

       

      I'm wondering how others handle it?

       

      Kyle

        • 1. Re: Where do you store your version number(s)?
          lexan

          From the standpoint of operational simplicity, I suggest you to:

           

          a) store the version of the "whole" Solution (BTW you release new version of your solution, not new version numbers of a calculated field)

           

          b) keep a track of your work on every single aspect of the database (plus some little things more...)

          As you know globals fields are global to the whole FMP session, but with an important caveat: *global fields* are *global* only by the point of view of the singe user".

          So that PIXI has written is not completely true!

          In order to show the same global fields to all users of a shared fp7 file, you should remeber to change them by opening the file in single user (locally), not from a FileMaker Server hosting it!!!!

          Keeping track of modified objects, dates, who, what, why, status, priority (and as many other attributes as you like) will help you to better maintain your solution!

           

          IMHO the best way to accomplish it is having a:

           

          1) "SOLUTION" table with a single record, where you can store any global information about your solution: its name, version, splash screen... in standard fields (global checkbox OFF!)

          You are free to relate this table with all others of your solution —with cartesian relationships— or to populate a serie of global fields at startup and to use them without needing any relationship.

           

          1) "DEVELOPER_LOG" table where storing not only any change you have done to the db schema, layouts, scripts... but even the changes you would like to do in the future and the status of any current changement —at some point in the day you leave your desktop and go to sleep, leaving open some tasks...

           

          /stefano

          • 2. Re: Where do you store your version number(s)?
            SusanneWaher

            Hi Kyle,

            I use the data separation model for my vertical solution (2 files - UI and data). Instead of using a global field or a separate file as the two other folks suggested, I created calculation fields in both files. I then use a relationship to display both version numbers discretely on the main screen so it can be seen if needed. One field is just the version number (text) "12.3.1".  The other field is a log /*comment*/ where I add a date and short description of the changes made in that particular file. I do this separately for the UI and the data file. Using a calculation field instead of globals or start up scripts makes it foolproof and removes the need to worry about if the version number will display depending on how the customer uses the database.

             

            As Stefano says, the whole solution gets rev'd (which is the first number) but I do keep track of small bug fixes with the numbers after the dot.  For example 12.3.1 The first number is the verison which contains the various features and functions of that version (12). The number after the first dot (3) is for any bug fixes or tweaks I've done in the UI file since the release of the featured version. The number after the second dot (1) is for any tweaks or bug fixes I've made in the data file since the release of the featured version. Having a log in the file itself is a convenience for me. If I'm providing tech support to a customer onsite or remotely I can go into field definitions and read my log if necessary.

             

            At home base all changes I make are recorded in a Development/Bug database for that solution which includes the date the change was made, the originating version number and the new number plus a description of the problem or feature. In this way I can easily determine what issues might come up for a customer with a previous version and send them a patch. I keep track of what version my customer has in my customer database. Lots of tracking going on but the system has served me well over the last 18 years. The right way is the way that works best for you!

             

            Susanne

            • 3. Re: Where do you store your version number(s)?
              DavidJondreau

              I would probably use a custom function.

               

              Something like:

               

              Version()

              = 11.04

              • 4. Re: Where do you store your version number(s)?
                Stephen Huston

                I have a table in each file of a solution for "settings". There I place a few globals for use in dialog boxes and things like Developer, Version, etc. These later fields are unstored calculations where I enter my name, contact info, versioning number, etc.

                 

                This allows me to update the version and version date any time I work on a file. I can even comment out old versioning info in the calc so I have a personal record of when things were done when I edit the calc, with only the latest info returned by the calculation itself for use on layouts or script tests.

                 

                I also comment all fields and scripts so I have an annotated record of when and why changes were made along the way.

                 

                I wish the files I inherited had something similar, but most are too old and previous developers didn't adopt the habit when commenting was introduced. I use it for my own protection, so I will know what I did months and years later.

                • 5. Re: Where do you store your version number(s)?
                  techt

                  stefano has an approach I've used, but I'm curious, other than an adherence to the separation model, is there a reason for the mutli-file solution? It did take me a couple of years to adopt after FMP7 came out, and the ease and speed has certainly justified the "re-training." If two files are required, then Stephen's direction would be one I would take. I would certainly avoid the field as a global for the reasons previously stated.

                  • 6. Re: Where do you store your version number(s)?
                    KylePutzier

                    I use a multi-file approach for a similar reason that people use the data-sep model. I can develop on an offline master copy and not have to import the live data from a 50 table solution. I may have to import only 10 tables of live data. For me, the data-sep model is to much work for little benefit.  Many times I am making changes to both the layouts AND the field defs/schema. I just don't see the benefit. I may still not fully understand the data-sep model though.

                     

                    I also don't get the segmented version number thing. I just use the date (ie: 11212011). I suppose it makes sense if you are selling a more commercial product rather than the one of a kind solutions I am usually involved in.

                     

                    Kyle

                    • 7. Re: Where do you store your version number(s)?
                      Stephen Huston

                      The  two reasons I know for a multi-file system are:

                      • Separation Model
                      • Files migrated from pre-7 systems

                       

                      In a single file system, I would still put my dialog globals and my versioning calcs into a seaprate Table within that single file.

                      • 8. Re: Where do you store your version number(s)?
                        FCallanan

                        I've settled on a method I use for single and multi-file solutions. In each file I have a pair of tables: FileVersion and VersionHistory. The first has a single record to store the current version number and date. The second is a log file where I track each change task, date, version in which it appeared, etc. The two tables relate through a cartesian-type join (constantOne=constantOne). These table pairs are all represented (and joined) on a developer's page in the interface, for ease of entry. The interface also displays the concatenated version info on an About page.

                         

                        The actual numbering scheme I use is somewhat arbitrary, however. I'm not thrilled with that...

                         

                        Frank Callanan

                        Camden, Maine

                        • 9. Re: Where do you store your version number(s)?
                          LyndsayHowarth

                          I do pretty much the same thing.

                          -Lyndsay

                          • 10. Re: Where do you store your version number(s)?
                            Todd Geist

                            I store mine in the Next Serial Number of a field set to use serial numbers. This is the only place that you can update with a script but can't be cloned away.

                             

                            Todd

                             

                            --

                            Todd Geist

                            http://www.geistinteractive.com

                            • 11. Re: Where do you store your version number(s)?
                              shearn

                              Interesting Todd. I put mine in two places (we're still working on which is most convenient): a global calc in a utility table (1 record) and a global variable in the startup script. Both can now be displayed on a layout although the global variable is restricted to the same file. Both survive a cloning. I have put the global calc in both my interface file and data file but it's very rare that they get out of sync. Personally I find the global calc more convenient but I've also been doing it that way longer. Call me an old dog.

                              • 12. Re: Where do you store your version number(s)?
                                LyndsayHowarth

                                Yes Todd,

                                 

                                This is basically the function of my version history table. It is the serial number generated in this table which becomes the latest version... when sorted by reverse-date in the relationship and it's generation updates the master table for the settings.

                                 

                                I also store it on the About window and on the footer in each view... including small & grey on a print layout. This allows me to troubleshoot any issues by version.

                                 

                                I find this forces me to enter version notes... which are retained in the client copy.

                                 

                                - Lyndsay

                                I store mine in the Next Serial Number of a field set to use serial numbers. This is the only place that you can update with a script but can't be cloned away.

                                 

                                Todd

                                • 13. Re: Where do you store your version number(s)?
                                  Todd Geist

                                  Hi Steve.

                                   

                                  I am a big fan of having a Build Script. The script does everything required to ship a solution, including updated the version or build numbers.  So I need something that can be updated via a script AND survives cloning. So I shy away from having to enter anything by hand, like a caclulation dialog, or hard coded in a script.

                                   

                                  You can store more than just the version number in the next serial number space.  It can take either 100 or 250 characters. I foeget which.  But either one is enough to store build numbers, build dates, and the user name.  All that data can come in handy sometimes.

                                   

                                  Todd

                                  • 14. Re: Where do you store your version number(s)?
                                    FCallanan

                                    This is a slick trick, Todd! Although my "build scripts" are meant to retain my version numbers and notes, more than once I've reopened a timestamped clone only to ask "what version was this."

                                    I easily retrofitted the NextSerialValue scheme into my current development yesterday in minutes.

                                    Thanks.

                                     

                                    Frank Callanan

                                    Camden, Maine

                                    1 2 Previous Next