1 Reply Latest reply on Mar 3, 2017 8:20 AM by philmodjunk

    Table View Fields to Excel Export Fields

    rbickings

      Good Morning,

      I have a client that must use the table view in all their layouts.  They love the flexibility of resizing columns, adding and deleting columns, etc.  However, they would like to export their table view directly to excel without having to redo it in the excel popup.  I have hard scripted those fields in the export to excel script step which works until they want to change it again.  Does anyone have a way in which this could happen?  I know there is some things I've read on export to XML then to excel, but nothing really helpful.  They are coming from an old database that allowed them to pick display fields and then those same fields could be exported to excel.  Any help would be greatly appreciated.

       

      Thanks,

      Rbickings

        • 1. Re: Table View Fields to Excel Export Fields
          philmodjunk

          There is a tool mentioned elsewhere here that may serve for exporting the data. Hopefully someone will find a post for it and post a link. You might also check the "Save as Excel" option to see if it works for you.

           

          But if your users insist on only table view and must export all data to excel at all times and in any format, I have to question whether they understand what is possible in Filemaker and if they shouldn't just keep all their data in Excel.

           

          Table View, in my opinion, is most useful to the developer, rather than the user, as a quick flexible way to look at a lot of data all at once. For the average user, they encounter a number of significant limitations/issues that can make supporting them a headache for the developer:

           

          1. You see the actual field names and Modify makes all fields in the solution accessible on the layout unless you have used Manage | Security to block access. Actual field names such as __pkTableNameID can confuse the user generating questions asked of you. Finding fields to display can require a working knowledge of the relationships and table occurrences or you get "I added field "xyz" to the layout but I don't see the right data."
          2. While resizing and re-ordering columns is nice, users are known to "lose" columns by making them too narrow to see and then you have to go in and "fix" the issue for them.
          3. You can't put buttons or other controls into the rows of the view  like you can in list or form view to facilitate a more user friendly interface. You can only set up script triggers (to take the place of buttons) and can only select data entry formatting (value lists) for fields physically present on the layout when you view it in layout mode.
          4. There's a limit on how many columns can be viewed at one time that is a function of the total width of every column rather than the number of columns. A user adds another column only to report: "I added a column, but can't see it" because they have exceeded that limit.