Tweet
We are on the latest March 14 release. When I enter '0001-01-01' in a date field the update just ignores it and returns to records list. All other updated fields are also ignored. There is no browser network activity in debug and nothing showing in the console. The table has multiple date fields that start as *loval but I can't reset any back to '0001-01-01' using Nitro File Editor.
-
-
What is the default date format for that instance? The format is set in Portal Admin > Settings > Portal Appearance > Date Format. -
Date format is YYYY-MM-DD.Comment
-
Our 'Live' instance has date format set to DD/MM/YYYY and it works. Date '01/01/0001' sets the date correctly to *loval ('0001-01-01').Comment
-
Sorry, one more test...
The 'Live' instance updates the date wrongly in the DD/MM/YYYY format. I entered 01/06/2023 (1st June) but it updated as '2023-01-06' on the file. However, the display on the records list shows it as '01/06/2023' which we interpret as 1st June but he file physically updates as January 6th.Comment
-
It appears you've stumbled on an obscure bug here. It turns out File Editor is sending dates to the back-end in the same format shown in the edit window. If that format happens to match the date format associated with the CGI job, which in your case I gather is MM/DD/YYYY, then SQL will accept it, provided it's a valid date in that format. If it's not valid (i.e., what it interprets as the "month" segment is greater than 12) then it will generate an SQL exception and abort the record update altogether.
The fix would be to have the front end of File Editor always convert date fields to *ISO format before passing them to the back end, same as NAB apps do. We will try to get this resolved in this month's build.
Thanks for the heads up!Comment
Comment