5 Replies Latest reply on Apr 29, 2013 6:34 PM by kap

    Using a copy of the database file (in a Runtime solution)

    kap

      Hi,

       

      Sorry if this isn't the correct discussion area to post, I couldn't find one more appropriate.

       

      I'm creating a filemaker runtime solution.

       

      Runtime name is: db_program.app

      Database filename is: database_file.USR

       

      My question:

       

      It seems that both db_program.app and database_file.USR need to be kept together in the same folder created by Developer Utilities for the runtime solution to function and that the best way for the user to work is to create a copy of database file, which they could then put wherever they wanted (i.e. leaving database_file.USR untouched).

       

      Is this correct? Are there any advantages/disadvantages to doing this?

       

      Kind regards,

      Kap

        • 1. Re: Using a copy of the database file (in a Runtime solution)
          MicheleOlson

          Hi Kap,

           

          What is your objective in creating the runtime solution?

           

          It is not clear to me why you would want the user to work on a copy of the data file.

           

          Ideally, the data file should stay in the runtime folder, but once bound to the runtime app, opening the file will open the app and vice-versa. An issue could arise if you have multiple copies of the datafile on the same computer, the app will open the one it finds first which is likely inside the folder. This could cause some *lost data* issues if the user opens one data file one time and a different one the next.

           

          Are you looking for a way to give the user quicker access to the file than searching through a folder for it? If so, create an alias or shortcut to the file or app and put that in a location the user can find.

           

          If your runtime solution will be distributed to many users, you can create an installer that puts the runtime folder in the correct location and puts an alias to the data file on the users desktop or wherever would be a logical starting point for them.

           

          Michele

          1 of 1 people found this helpful
          • 2. Re: Using a copy of the database file (in a Runtime solution)
            kap

            Hi Michele,

             

            > What is your objective in creating the runtime solution?

             

            Users would be part of a research study. I want them to be able to enter information in a database I've set up, but it wouldn't be reasonable to expect them to each purchase a copy of Filemaker Pro in order to do so.

             

             

            > It is not clear to me why you would want the user to work on a copy of the data file.

             

            1. Users would be more empowered to be able to replace the database file if it became corrupt. It would just be a matter of deleting the corrupt file and replacing it with the most recent backup (as opposed to needing to understand that it needs to be located in a specific folder and be renamed a specific way).

             

            2. I could provide a second "training version" of the database file. i.e. One that was preloaded with fake data that users could feel free to experiment with in order to become comfortable using the database.

             

             

            > Ideally, the data file should stay in the runtime folder

             

            It doesn't seem to me that this is an option. From my experiments moving/renaming this file stops the application from working.

             

             

            > An issue could arise if you have multiple copies of the datafile on the same computer,

            > the app will open the one it finds first which is likely inside the folder.

             

            I'd provide a specific warning to users to always launch via their database file and ignore the app/runtime folder altogether.

             

             

            Kind regards,

            Kap

            • 3. Re: Using a copy of the database file (in a Runtime solution)
              PeterWindle

              Just to throw your mind into a real spin,

               

              I have developed a solution (run time) that uses a data-separation model with 3 files, for example:

              Solution_GUI.usr

              Solution_Data.usr

              Utility.usr

               

              so that the following can occur:

               

              1. The "GUI" file - has only layouts, scripts and relationships can be replaced for "upgrading" purposes.

              2. The data file can be replaced easily (restoring from backups)

              3. The current data file can be transported easily from a bound desktop solution to an iOS solution.

               

              Most of the functionality is driven from the 3rd Utility file. From there, I can close off the other files to perform functions like restoring a file from backup. How? The existing data file gets backed up (save a copy as), with a unique name (time/date included) , the current file gets closed off .... then whatever data file you're restoring from gets saved as the current data file (Solution_date.usr), thus giving you the data that was in the data file as the file the GUI uses to display.

               

              Upgrading the solution is as easy as replacing the GUI file (backups are performed first)

               

              I have also made a second GUI file that also uses the same DATA file, the GUI file is designed to be used on the iPad. To start with, the iPad GUI file and data file is copied to the iPad, then if the user wants to move the data from desktop to iPad, they close the existing solution, copy the DATA file from one platform to the other. (NO SYNC, just transportability)

               

              MAJOR CAVEATS!!!

              this assumes that the DATA file would NEVER change from it's original design. If you have a problem with a field, for example, upgrading the solution won't fix it. Restoring a backup file may resurrect problems with the fields and realtionships that might exist within that files's design.

               

              The DATA separation method has it's drawbacks.

               

              The DATA separation method is also frowned upon by FileMaker Australia (which makes me cranky, because there are some MAJOR solutions out there that use the same techniques.)

               

              Is this making sense to you?

               

              If you need more info, email me peter.windle@mac.com

              1 of 1 people found this helpful
              • 4. Re: Using a copy of the database file (in a Runtime solution)
                MicheleOlson

                Hi Kap,

                 

                Interesting project it would seem.

                 

                In my experience - both Mac and Windows - I can put a copy of a runtime datafile on my desktop while the original file and engine lie buried many folders deep. If I double-click the desktop copy, it does launch the runtime app.

                 

                If you do offer your users the option of opening the datafile with FileMaker, you will likely need to give them instructions on doing so. Double-clicking or opening the bound file will always want to open the runtime app if it exists on their computer - as long as the file retains its original name and bound extension. When I want to open a runtime data file with a full copy of FMP/A, I usually drag the file to the app or app alias/shortcut, or if the file is to open permanently with FMP/A, just rename or change the extension.

                 

                My question

                > It is not clear to me why you would want the user to work on a copy of the data file.

                Your reply

                1. Users would be more empowered to be able to replace the database file if it became corrupt. It would just be a matter of deleting the corrupt file and replacing it with the most recent backup (as opposed to needing to understand that it needs to be located in a specific folder and be renamed a specific way).

                 

                This is interesting. Why do you expect the data file to become corrupt? And if it is replaced, wouldn't they lose all the data they have entered?

                 

                 

                Your reply

                2. I could provide a second "training version" of the database file. i.e. One that was preloaded with fake data that users could feel free to experiment with in order to become comfortable using the database.

                 

                You could also build this into the solution. Have it set with fake data and provide a button to delete all data and start fresh once they had a comfort level with the concepts.

                 

                My comment

                > Ideally, the data file should stay in the runtime folder

                Your reply

                It doesn't seem to me that this is an option. From my experiments moving/renaming this file stops the application from working.

                 

                Moving the file does not stop it from being bound to the runtime app. Renaming the file does remove its connection to the runtime app.

                 

                Regards,

                 

                Michele

                • 5. Re: Using a copy of the database file (in a Runtime solution)
                  kap

                  > This is interesting. Why do you expect the data file to become corrupt?

                   

                  It seems that Filemaker Inc. makes it pretty clear that database files can become corrupt (and if a Runtime solution limits access via password protected accounts, which mine does, they can't/won't repair the file). In any case, it's more about empowering the users and encouraging them to keep regular backups than any big concern I have about file corruption.

                   

                  > And if it is replaced, wouldn't they lose all the data they have entered?

                   

                  I'm assuming they're replacing the file with a reasonably recent backup. Can't do anything for them if they haven't backed up the database (or can I? - I toyed with the idea of just automatically creating a backup database file on the Desktop every time the database was launched, but decided that would be too annoying to users).

                   

                  > You could also build this into the solution. Have it set with fake data and provide

                  > a button to delete all data and start fresh once they had a comfort level with the concepts.

                   

                  Interesting idea (I actually already have this functionality hidden away for development purposes), but then I'd be taking the chance of them pressing the button accidentally on the real database.

                   

                  > Moving the file does not stop it from being bound to the runtime app.

                  > Renaming the file does remove its connection to the runtime app.

                   

                  Ah - yes. Still reinforces the idea in my mind that this file is best left untouched/unknown by the user though.

                   

                  Kind regards,

                  Kap