Harry Posted September 26, 2014 Posted September 26, 2014 Hi Board! I have a User Interface that allows scanning and registering and validation of loads of information. The last part of the script scoops up all the inputted data and then sets it as variables and then writes to a table. The last step is: Set Field [Job_Logging_Home::Timestamp_Scanned; Get (CurrentTime)] It has been working fine for weeks and then has stopped working. I've checked through and the data is being written, but the Timestamp is returning as 01/01/0001 01:01:01. The Client machine that is running the script has the data correctly set. If I add a 'Set Field [Job_lo.....::Timestamp; 22], for example, it writes to the table as 22. So somewhere along the line it is not Get(ting) the correct time. Can anyone help with some guidance of where i should look for this solution? Thanks, Harry
comment Posted September 26, 2014 Posted September 26, 2014 If the field being set is a Timestamp field, then you should set it to Get ( CurrentTimestamp ) or Get ( CurrentHostTimestamp ). When you set it to Get ( CurrentTime ), Filemaker will convert the current time to a timestamp - and with no date being given, it will use the first date on its calendar.
Harry Posted September 26, 2014 Author Posted September 26, 2014 Actually, scratch that. It doesn't work if i try to set it to '22'. It does set the time correctly but not the date. The date is always 01/01/0001
Harry Posted September 26, 2014 Author Posted September 26, 2014 Brilliant, thank you very much Comment! Don't know why it was working before and now it's changed. But that's moot now it's fixed. Thank you. I had no idea the timestamps were all calculated differently like this, thanks. Harry
keywords Posted October 5, 2014 Posted October 5, 2014 I've only just seen this post from a week or so back, but here is a thought. "Comment" said: "with no date being given, it will use the first date on its calendar". I am not so sure about that; it could use the current date as the default date—it would be more logical. Here is why I think this may be so. The behaviour you report looks suspiciously like behaviour I have seen on computers in the past when their internal battery died. When a computer is switch off it has an internal battery to delivery just enough power to maintain some internal storage of things like its internal clock—that is why you don't have to reset those things every time you restart your computer. When this battery dies the clock stops; an indicator that this has happened is that the date on the internal calendar has reverted to 01/01/0001. You can reset the date and carry on as normal, but when the computer is shut down … you get the idea. So, Harry, IF the computer on which you are seeing this change of behaviour is one which is shut down regularly—or perhaps was shut down and restarted just before this started to play up—the cause may simply be that it needs new internal battery.
comment Posted October 5, 2014 Posted October 5, 2014 "Comment" said: "with no date being given, it will use the first date on its calendar". I am not so sure about that; it could use the current date as the default date—it would be more logical. It's not a matter of what you or I think would be logical. It's a deterministic behavior of a system that can be tested.
Recommended Posts
This topic is 3758 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now