12 Replies Latest reply on Aug 16, 2017 3:47 PM by cranstonit

    moving database from MAC to PC -- field slippage

    quirkycrone

      For some reason fields in forms are being replaced unintentionally.  A field from one table is basically being designated as another table/field altogether.  Because I develop on the MAC, and use a PC as a server for my remote client, I am wondering if this phenomena I call field slippage is related to moving the file from the MAC to the PC, or vice versa?  Has anyone else encountered such "ghost" maneuverings? There doesn't seem to be anyway to "lock down" the fields selected, and there should not be any need, but it is a rather frustrating problem...

       

      Suggestions are most welcome.

        • 1. Re: moving database from MAC to PC -- field slippage
          philmodjunk

          You'll need to describe how you are moving that solution from Mac to Windows.

           

          Simply placing a copy of the file from your mac onto a windows system or server won't put the data into different fields.

           

          There could be display differences, usually minor due to the fact that the font metrics for Mac and Windows are not the same. The same text on the Mac takes a few pixels more space on windows. This can cause text, both layout and data in fields to be either clipped or "wrap" differently than on the Mac. But usually, a few minutes tweaking the layout while in layout mode in windows is all that is needed to eliminate this and the resulting copy should then look fine on a mac as well.

           

          The same font metrics issue can affect FM GO when you first deploy a modified copy of your solution to an iOS device.

          • 2. Re: moving database from MAC to PC -- field slippage
            cranstonit

            As I understand the problem, data entered into TableA::Field1 field is ending up in TableB::Field2.  If this is the problem that is a bizarre issue.    Here are some thoughts

             

            1) Cross Platform development will not cause this issue.  We routinely develop on Mac and deploy on Windows (Servers and Clients).  Aside from minor formatting issues like philmodjunk mentioned we've never had any issues with the database file.

             

            2) Check to make sure clients are accessing the layout you think they are accessing.  Maybe they are getting onto a different layout and entering data into the wrong fields.

             

            3) When a layout is in Browse Mode it's essentially locked down.   However you configured the layout is what the user will see.  Make sure users don't have access to "Layout" Mode where they could make changes.

             

            4) Check your scripts and calculations.  If you are moving data around using scripting, auto-enter calcs. etc.., a mistake in the scripting or calculations or cause data to be placed in the wrong fields.

            • 3. Re: moving database from MAC to PC -- field slippage
              philmodjunk

              And there can be issues if you are using import records to move data from old file to new copy or if you have different "front end" files accessing back end files if you aren't careful in how you manage any changes to the fields and tables of the back end file.

              • 4. Re: moving database from MAC to PC -- field slippage
                philipHPG

                Are you developing in one database and then copying and pasting scripts, layout objects, etc into a different database? I have sometimes seen this in such situations when fields aren't created in exactly the same order in both databases. Internally FileMaker stores references to fields using IDs that are generated when the field is created. So if fields aren't created in exactly the same order in the new database, copying and pasting scripts and/or layout objects may reference a different field.

                • 5. Re: moving database from MAC to PC -- field slippage
                  philmodjunk

                  Yes, FileMaker internally stores references to fields by ID, but when you paste a script, it uses the name in the script to find the ID in the current file before updating to use the target file's ID for that field, so this should not result in an apparent name change in the script after pasting.

                  • 6. Re: moving database from MAC to PC -- field slippage
                    quirkycrone

                    In answer to multiple questions..

                     

                    1) I initially just wondered if the fact that I am moving the entire database cross platform was causing the problem.

                     

                    I am finding many strange issues: the worst by far being when the table on a given layout gets changed. Othertimes the specs on a perform find are changed, or the field where I pick from a value list is designated by a different table:fieldname set than the one I configured it with.  I would suspect sabotage except that there is a very small set of users, myself, my niece (who owns the database), her husband, and a student who works for them.

                     

                    However, I did find another thread on here that talks about importing records in this vein. Since the only way I have found to update a database (when one database is being used (remotely, froM PC), and records are being added or modified: and the last saved copy of the database is being used as a working file to modify and test on the MAC, and since Filemaker does not have an "Append from" function, is to export the current PC version to a MER file, moving the database from the MAC to the PC, dump the table and import the records from the MER file, I would imagine this is creating the havoc, maybe?

                     

                    Unfortunately, it is tortuous.  And because it appears it can change scripts and finds, etc, means (I gather) I have to test every little piece of the database before I can turn it over to my users.  This is a royal PITA as I have just tested it in work space.

                     

                    Also, Phil, I don't get what you mean by "front" versus "backend" files?

                     

                    Nearly every time I move the Database from the MAC (my workspace) to the PC (where my client enters real data, remotely) I have to dump and recreate at least 2 tables: clients, sales and sometimes surveys. Other than examining the import tree minutely -- I'm not at all clear on what to do. Other than test everything again before turning it over to the client. It's a very unreliable way to proceed to say the least.

                    • 7. Re: moving database from MAC to PC -- field slippage
                      philmodjunk

                      Here's the key to your trouble:

                       

                      However, I did find another thread on here that talks about importing records in this vein. Since the only way I have found to update a database (when one database is being used (remotely, froM PC), and records are being added or modified: and the last saved copy of the database is being used as a working file to modify and test on the MAC, and since Filemaker does not have an "Append from" function, is to export the current PC version to a MER file, moving the database from the MAC to the PC, dump the table and import the records from the MER file, I would imagine this is creating the havoc, maybe?

                      The problems you report strongly suggest that you messed up the data imports, importing data into the wrong tables or wrong fields.

                       

                      First: You don't have to export to a merge file to update a solution with a new copy of the file. You can deploy a clone of the new copy of the file, import all data directly into the clone (no exports needed), then swap the new (formerly clone file) for the original copy. (Keep the original closed or paused during this import so that users can't modify data in the original.) This can be scripted so that all data is imported correctly and you can test run the script on back up copies before you do it for real to make sure that all will work as expected. (If you use serial number fields, be aware that they will likely need updating and this can also be done via script.)

                       

                      360works, BTW, is about to release a tool that automates the above process for you to make this easier and more fail proof.

                       

                      Then your question about "back end" and "front end" brings me to a way to reduce the cases where you might need to import data during an update. You can use a method called "data separation" where your layouts, scripts, etc are in one file, the "front end". Your tables can be in a second file the "back end". They are also called UI or "interface" files for the front end and Data files to describe the back end.

                       

                      With such a set up, you can deploy updated interface files without having to do any data imports.

                       

                      PS. It's also possible to deploy an update to a FileMaker file, if it involves a layout or script change simply by opening the hosted file and making the change there. I often open the hosted file that I maintain and copy paste layout objects and/or script steps from a development copy into the hosted copy.

                       

                      If you research this forum, you'll find a number of discussions on methods used to maintain/update solutions that go into some of these options in more detail as well as warnings of what can go wrong with some of them.

                      1 of 1 people found this helpful
                      • 8. Re: moving database from MAC to PC -- field slippage
                        quirkycrone

                        Thanks Phil! This was very helpful!

                         

                        I think the front and back end solution makes sense in my scenario.  I have a question, one that is difficult for me to test because it requires two internet connections. If I create such a solution and link the data (back-end) database to the front end using External Data Sources, do I need to have my client open the back-end file through the IP, or would it be sufficient to merely have it open on the PC?

                         

                        Will I have to re-establish the External Data sources every time I update the front end?

                         

                        At least this solution offers hope of creating a more stable functioning environment.  Which has certain merits...seeing as how this is supposedly a database!

                        • 9. Re: moving database from MAC to PC -- field slippage
                          philmodjunk

                          There are pros and cons to data separation and it doesn't eliminate the need for data exports, just reduces the need.

                           

                          When you open file A and something references data in File B (such as fields on the current layout pulling data from a table in another file such as is the case with data separation), FileMaker attempts to automatically open File B using the info in the external data source reference to find and open it and it uses the credentials used to open File A to open File B. If the External Data Source reference can't help FileMaker find the file. (The file has a different name, it's been moved....) you get a dialog asking you to find the file. To make this dialog stop appearing, you have to update the external data source reference. So as long as you keep the two files in the same folder, either on the  PC or on the server, you do not need to update the external data source references when deploying a new copy of the front end. And if File B requires different credentials to open than File A, you get a password dialog asking for log in Credentials.

                           

                          Managing different user access levels and scripts that run with "full access privileges" will raise a few issues that require a bit of extra effort to resolve. Your relationships in both interface and data files can be identical, or you can limit the relationships in the back end to just those needed for data level things like calculation fields that reference related data or look ups and limit those in the UI file to those needed for your scripts, layouts and value lists.

                          • 10. Re: moving database from MAC to PC -- field slippage
                            quirkycrone

                            with the file separation model WHAT HAPPENS when you move a new UI into the picture? Does it just automatically attach to the data containing "back ends"(providing the external data source is still configured)? What might happen if you attached the UI to a version of the backend that had a modification to the data schema?  (IE;, the tables were there but were not identical to the version you were testing the UI with?)

                             

                            The extent of the damage that occurred apparently after I ADDED a field to a table was so extensive (how in the dickens does filemaker change the parameters of a "find" in a script? all by itself?) that I really don't want to revisit

                            this.

                             

                            I've looked through the threads and a white paper on fie separation and the best I can say is that I don't find much about problems of this ilk.  I am wondering if one just replaced the external data connection there might be less impact because the scripts within the UI database would be less likely to respond dynamically to imports. Maybe?

                            • 11. Re: moving database from MAC to PC -- field slippage
                              philmodjunk

                              In normal operation, and with a few special exceptions, FileMaker references data in a field via unique IDs assigned at the time the field is defined. Each table, table occurrence and field gets such a unique ID at time of creation.

                               

                              Generally, this works very well for us. If we change a field, table or table occurrence name, nearly all references to the data still work because we changed a name, not one of these IDs. (If you think about how we work with primary keys in a database, this basic design logic should make a lot of sense.) When we open something that lists the name of a field, such as the scripts workspace or the specify calculation dialog, FileMaker uses those ID's to look and and display the name. If you edit a calculationor script step, you enter or select a field by name, but when you click OK to save the changes back into your solution, FileMaker uses those names to look up and store the relevant IDs. Please note that what I just said is by inference, not something for which I have any inside knowledge.

                               

                              So with a front and back end, the front end uses an external data source reference to find the back end file and this enables you to add occurrences of the back end tables to the relationship graph of the front end. You can even have several different back end files if such a modular approach is warranted. And if you replace the front end with a new copy, this set up of external data source reference and table occurrences that use it should enable the new front end to work just fine.

                               

                              Where this can create an issue with data separation is if you add 3 new fields to a table in a back end file where you are developing a new solution, update the front end to use them. And then try to use the front end with a different copy of the back end where someone tried to add the same fields or made other matching changes to tables and relationships. Even though the names are exactly the same, those internal IDs might not be the same and then the wrong date appears in the field on the front end's layout.

                               

                              But if you are using a script to import records, there are other problems that have nothing to do with this form of data referencing. You may have gotten the fields misaligned in the import records script step (or equivalent menu option) and adding/removing fields to the target table has been known to misalign fields in an existing script step if you don't use the "matching field names" option. This was fixed in version 13, but have this nagging memory that the problem has resurfaced so this is something to be very careful about.

                              • 12. Re: moving database from MAC to PC -- field slippage
                                cranstonit

                                with the file separation model WHAT HAPPENS when you move a new UI into the picture? Does it just automatically attach to the data containing "back ends"(providing the external data source is still configured)? What might happen if you attached the UI to a version of the backend that had a modification to the data schema?  (IE;, the tables were there but were not identical to the version you were testing the UI with?)

                                It will look for the data file and automatically attach to it.  If you only made changes to the UI file everything will work as expected.  If you made changes to the data file you would need to make those changes to the production data file or do a data import from the "old" version of the data file to the new version of data file.

                                 

                                Anytime you are working with two versions of the databases (i.e. a development version and a production version) there are many complications when trying to update.   The Split data model helps when you are only making changes to the UI file.  In this scenario just swapping out the UI files works seamlessly. 

                                 

                                If you make any changes to the data file you are back to a more complicated update process of either duplicating the changes originally made in the development file in the production file or building a scripted import routine that helps automate the data import from one data file to the other.