5 Replies Latest reply on Jan 2, 2014 10:53 AM by RichardKirkman

    Different solution to date field question mark

    RichardKirkman

      Title

      Different solution to date field question mark

      Post

           *EDIT: THIS FIRST POST DOES NOT RESOLVE THE PROBLEM. SEE POSTS AFTER THIS. [I'm only leaving this post in case someone wants to try any of the steps mentioned in the replies]*

           Ever since I had updated to FMPro 11, I've had trouble with the date fields in my forms displaying a question mark. If I clicked in the field, the current date would display, which was what it was supposed to do—automatically enter. But once I tabbed out of the field, it reverted back to a question mark. Also, during that period when the date did show, the slash mark separators in the date were missing. I took this as a clue and tried all sorts of things from changing date formats to fonts. I tried changing the size of the field in case it was too small to display the date (though it had always been fine in previous versions). I deleted it and put the field in again. Nothing ever worked. 

           Today I found the solution. I tried to check the definition of the field. Everything was fine. Then it occurred to me that maybe there was a duplicate date field and I might be using the wrong one, or it was conflicting somehow. 

           My date field—that I'd been using for years, through at least 6 or 7 versions—was called "Invoice Date." I scrolled through the list of fields and came to one at the bottom that I didn't recognize: "Today." I never created that field. In the Comment for it, it said "Generated by conversion." All I can think is that when the files were converted for the new version, it generated the "Today" field, and no longer recognized the old "Invoice Date" field. When I looked at the options, it had the same options as my old field, so I tried it. I replaced the Invoice Date field with the Today field, and now it fills in correctly and stays entered now. 

           This should be considered a bug, and it's caused me many hours of frustration trying to fix it. An update and the subsequent file conversions should not be messing with your user-defined fields. Nowhere in my searches for a solution for this over a long time has this ever come up as a reason. Maybe my case is unique, but just in case it isn't, I want to let people know to look for this. 

            

            

      Filemaker-today-field.png

        • 1. Re: Different solution to date field question mark
          philmodjunk

               I suspect that this file started out as a very old file, maybe created in FileMaker 3?

               Once upon a time, you could define a calculation to have a date result using the Today function. This function, which no longer exists in current versions, allowed you to have a stored, indexed calculation field with today's date in it. The drawback to this function was that when you first opened your database, the system ran through all the records in the table and recalculated this date field to put the correct today's date into it. As FileMaker tables have come to store ever larger numbers of records, this could bring your entire database system to its knees just by trying to open the file.

               Current versions of FileMaker do not have this function. Instead, you use Get ( CurrentDate ) and keep the calculation as an unstored calculation and thus this issue is avoided, though the change required some adjustment for some existing solutions.

               Since this function was deprecated, the file conversion software was written to include code that enabled files that used theToday function to still work in the new release that no longer had that function. As I recall, the conversion software added a date field--the Today field that you found and also added a script to update the Today field each time that your file is opened. That script would have been selected in File options to run when the file was opened.

               I don't really see how the presence of that Today field would have any impact on the question mark issue that you are dealing with. A date field with a question mark is usually due to one of three causes: a) the field is simply too narrow to display the date as formatted by the selected data formatting options or b) there has been a change in field type and/or date locality settings that has messed up FileMaker's ability to correctly display the date or c) the file or the date field's index has been damaged.

          • 2. Re: Different solution to date field question mark
            RichardKirkman

                 I'm sure this file goes back that far and has been updated and converted many times.

                 As I said, I'd never used a Today field. My field was always "Invoice Date." And Invoice Date was always, and still shows as, a Date field—entering the Current Date, not a calculation.

                 After the update to FMPro 11, the Invoice Date field stopped working even though it was set to enter the current date Automatically. Everything in the Inspector for that field was correct: how it was entered, the date format, font, color, etc. And it's the same settings the newly discovered Today field has. For some unknown reason, my Invoice Date field just stopped working when I updated to v11.

                 The Invoice Date field always entered automatically when tabbing to the field. It never updated to the current date when the file was opened. It always stayed the original date when the record was created. I've gone through numerous updates and file conversions over the years and this update was the first time this has ever happened. 

                 As for your listed reasons why the field would display a question mark: 

                 a) As I noted in my post, I changed the size of the Invoice Date field much larger and it still had no effect. (that was the first thing I tried after researching this problem, and I tried it numerous times since)

                 b) There were no changes in the field type or date locality. All those things were checked many times. 

                 c) Possibly the date field's index was damaged, but I doubt it. All other dates that had been set through the years were still correct. This only happened in new records or duplicating a record to use as the basis for a new record. 

                 I wonder now if tomorrow the date on my invoice will change to tomorrow's date, or if it will remain intact as the date the record was created. So maybe this won't be the solution I've been trying to find. I'll know tomorrow. 

                  

            • 3. Re: Different solution to date field question mark
              RichardKirkman

                   @PhilModJunk—Well, that didn't work. The Today field just kept updating the date to the current date—I should've thought of that earlier. Funny thing, though. When I went back and replaced the field with the Invoice Date again, and all but one of the most recent invoice dates filled in correctly.

                   Before, when I'd replaced the Invoice Date field to solve this, they still had question marks. This time only one of the four most recent still had a question mark. Weird thing—I duplicated the record that still had the question mark and it filled in with the Current Date, just like it was supposed to. So I overrode the date to make it yesterday's, to be accurate, and deleted the remaining record with the question mark in the field. 

                   I don't understand why 3 out of the 4 would have corrected themselves, and one wouldn't. They were all using the same field and created the same way. Yesterday all four had question marks. 

                   Anyway, somehow it seems to have been resolved. Thank goodness, since this has plagued me ever since I updated FMPro to v 11 a couple years ago. So my solution didn't work in the end, after all. And I'm still left not knowing what went wrong or how it really resolved itself. 

              • 4. Re: Different solution to date field question mark
                philmodjunk

                     It wasn't originally a field. It was a function. The Today field was added during conversion to a new file type for a new version of FileMaker that did not have the Today function. Presumably, there was a calculation field somewhere in your system that used the today function as that would be the reason you found such a field in your table.

                • 5. Re: Different solution to date field question mark
                  RichardKirkman

                       My guess re: Today field is that it was a function included in the original template I'm using (from my version in 1994) that I never had any encounters with. I don't use all the reports or forms in the template. So when the update (whichever one that was) turned it into a field, I never noticed since I don't use the function. 

                       My only interest in the Today field was that it seemed to fix my Invoice Date problem, for which I was mistaken.

                       Still don't know why the Invoice Date problem occurred or how it sort of resolved itself. I have seen other posts online that had the same problem, but not all the solutions worked for everyone. It was typical, though, that it included missing slash separators in the date. And in this latest instance, when 3 of the 4 invoices became correct after putting a new Invoice Date field into the layout, replacing the old one, the record that it did not fix was missing the slash separators. Duplicating the record not only restored the correct date entry, but the separators returned as well.

                       You would think that some index damage would have affected all the Invoice Dates, but it didn't. The problem only occurred in the field for automatic date entry when the record was created. Just before tabbing in—question mark in the field; tab into the field—the date filled in without the slash separators; then, tabbing to the next field—the date reverted to a question mark. 

                       Anyway, it's working now, and still a mystery.  

                       Thanks for your input.