2 Replies Latest reply on Mar 8, 2010 6:10 PM by e0d

    Recommendations for changing backing table for a layout



      Recommendations for changing backing table for a layout


      I'm no FileMaker expert, so I hope this isn't a silly question.


      I'm using FileMaker Pro 10.0v3 on Windows.


      I'm making some changes to an existing FileMaker application.  The changes include moving the data to a remote database using an ODBC connection.  The current use model is that data for a single year is kept in a copy of the database and a new copy is created for each year.  


      I had hoped that I could have a table per year and change the backing table for a layout and, since the backing tables are structurally identical, the layouts would transparently map their fields to the columns with the same name.  This doesn't seem to work unfortunately.  I'd rather not make a lot of change to the application or change the user's business process, if possible.  Are there any ways to seamlessly change the backing table for either the application or a particular layout?


      Any suggestions will be greatly appreciated.







        • 1. Re: Recommendations for changing backing table for a layout

          Hi Ed,

          If I understand your question correctly, you've discovered that a duplicate table doesn't share the same relationships as the original. Why keep the data in the table once it's archived? Just deleting all transferred records would keep your ODBC link intact and give you a fresh start each year. Alternately, you could add a date field on the table and transfer only a year at a time.

          • 2. Re: Recommendations for changing backing table for a layout

            You understand the issue.  Ideally the "archived" data would still be accessible, although the need to access it would be rare, so, while deleting it is possible, some mechanism for accessing it is required.


            The current application has 35 layouts that share ~200 fields so remapping them each year would be very tiresome.


            The best I have is to have two versions of the application.  One that is associated with an archive table that contains data for all years and one that is associated with a table for the current year.  This feels a bit ham fisted.