5 Replies Latest reply on Jul 25, 2014 3:09 PM by philmodjunk

    Many fields locked to editing from table view (edit: fixed!)



      Many fields locked to editing from table view (edit: fixed!)


           In the Filemaker 13 database I have been working on (Well, I'm using FMP13 and it's running on FMS13, but users use FMP12 or WebDirect), a peculiar problem just arose. Many of my fields (tempted to say every one made before a certain date, as there's newer fields that aren't showing this issue) can't be edited from table view! Here's an example of what a record looks like when I'm clicking down on a record (on this table, only the 4 "outlined" fields can be edited from table view; they don't seem to differ from other fields in any other particular way): http://i.imgur.com/XHVJwSY.png

           It's not a *huge* issue, but it's a lot easier to compare records quickly side by side as well as mass-edit/enter data through table view than it is through form, so I'd like to figure out what the problem might be. I've found nothing after a couple hours of searches that suggests it's even possible for individual fields to be locked to editing from table view (though I've found it's possible to lock records/rows individually, and you can't edit table view without Full Access privileges; neither of those fit this scenario, as entire fields/columns are locked here, but not all of them). I'll provide any other information that might help fix this, I'm just not sure what would be relevant right now.


           Edit: Fixed. Posted solution below, in case anyone else has this issue and is searching for the solution in the future.

        • 1. Re: Many fields locked to editing from table view (edit: fixed!)

               Can't tell anything from that image.  A complete image that included the header might have shown a clue--such as showing that the fields that can't be edited are from a related table or something.

               There are at several ways that come to mind that might keep a field in your table view from being editable:

               a) It's a calculation field and thus cannot be edited under any circumstances

               b) It's from a related table occurrence and there is no related record (and "allow creation.." is not enabled) linked to the current record on your layout.

               c) The field has been added to the layout while in layout mode and browse mode access has been blocked.

               d) The field has been added to the layout and a script trigger specified for the field that is performing a script that blocks access or editing on the field.

          • 2. Re: Many fields locked to editing from table view (edit: fixed!)

                 Here it is with header, just to prove none of these are from a related table: http://i.imgur.com/Hz0djoC.png

                 The only field here I'd consider "weird" is the a1 field, which is literally just a global 1 used for a few shortcuts.

                 In response to your lettered theories:

                 a) None of the pictured fields are calculation; there's only one calculation on this particular table, and I hid that field.

                 b) Obviously, these aren't related fields, as seen by the field names in my updated pic not having the format "table::field".

                 c) Hmm... I thought at least the old fields here (I can't even edit Serial Number, the cut-off field on the far left, which was the first field I made for this db) were created in table view, long before I began work on layout mode. But this sounds like a possibility; many of these fields *are* blocked from editing on the layout in browse mode in one of their occurrences, because I have 2 tabs on the actual form: one for viewing data, where all the fields are locked, and one for editing, where I can freely edit them. It's also worth noting that not one of the fields I've shown can be edited (a1, Notes, Sold Date, Sold Invoice) appear in the "locked" section of the form. This also applies to the editable fields in my other tables (including my non-layout tables being completely editable), with one exception: there is another "notes" field that can be edited from Table View, but appears on both tabs of its layout (though it's highly probable it was just in edit first and got it's locked form added to the other tab later). Assuming this *is* the issue, is there an easy fix, or am I going to just have to recreate the layouts with the "Editable" fields being made first?

                 d) I don't think this applies, but there is a script that runs whenever a field is committed which "updates" the a1 field with a 1, intended to keep calculation fields relying on Get(CurrentDate) accurate. I'd think I could at least click into the field if that was an issue, though, since the script doesn't run until commit.

            • 3. Re: Many fields locked to editing from table view (edit: fixed!)

                   c) Blocking browse mode access is layout specific. You'll need to enter layout mode and check for fields present on the layout while in layout mode to see if this is possible.

                   d) I considered this option highly unlikely, but since it is possible, I included it as the last one on the list.

                   An additional possibility is that your layout is damaged and it (or the file) should be replaced.

              • 4. Re: Many fields locked to editing from table view (edit: fixed!)

                     Found the actual answer to why the fields were locking (it was related to c, but that wasn't the whole picture). When a field appears twice in a layout, FileMaker apparently decides which iteration of the field to use to determine editability by judging which appears "first" (above and/or to the left of the other iteration, this ignores tabs) in the layout. So to fix the issue I had to reposition the Info tab stuff a small bit down and to the right, and the Edit tab up and to the left.

                     It feels like it would be better usability-wise if there was a checkbox in Field Options which determines table view enterability rather than something as trivial as layout positioning, but at least now I know how FileMaker currently determines this (and why the issue arose; I had previously rearranged the two tabs to "mirror" each other better, and the layout positioning differed by just a few pixels). I was worried that the file *was* damaged, so I'm glad this was at least under my control, even if the solution wasn't exactly well documented or ideal.


                     Edit: Ooh, this allows drop-down lists from table view too (At quick glance, seems to be grabbing all of the Data tab stuff from the Inspector), awesome! Guess I'll have to pay better attention to my positioning in my layouts from now on so Table View can use functions like this.

                • 5. Re: Many fields locked to editing from table view (edit: fixed!)

                       And why did you need two copies of the field on the layout when you are using table view to view the data anyway? Why not just remove the redundant copy of the field?