I am using FME 2018.1 32-bit and while reading an .accdb file, I am encountering this error "WARN |Microsoft Access Reader: The epoch time is out of range. Please ensure it is specified in seconds, and not in milliseconds or microseconds". Translation stops after this with a Fatal Error message. There are more than 2.5 million records in the table i am accessing. If I give a where condition an extract 100 odd records, it does execute. When i run the same Workbench in FME 2017.0 32-bit without any WHERE condition, it executes successfully. Any info on how can i troubleshoot this error ?
Solved
Epoch time is out if range
Best answer by chrisatsafe
Hi @bb,
Are you able to re-run the workspace with debugging turned on (Tools > FME Options > Translation > Log Message Filter > Select Log Debug). After running the workspace with debugging on, can you please upload the translation log?
It's tough to say without seeing the log first, but this may be related to a similar issue that is currently being looked into where the translation in FME 2018.1 is failing due to a bad feature or invalid date being read in from an Access Database. This is likely why you are able to read the first 100 features (other tables are likely unaffected by this).
+2- Contributor
- Best Answer
Hi @bb,
Are you able to re-run the workspace with debugging turned on (Tools > FME Options > Translation > Log Message Filter > Select Log Debug). After running the workspace with debugging on, can you please upload the translation log?
It's tough to say without seeing the log first, but this may be related to a similar issue that is currently being looked into where the translation in FME 2018.1 is failing due to a bad feature or invalid date being read in from an Access Database. This is likely why you are able to read the first 100 features (other tables are likely unaffected by this).
chrisatsafe wrote:
Hi @bb,
Are you able to re-run the workspace with debugging turned on (Tools > FME Options > Translation > Log Message Filter > Select Log Debug). After running the workspace with debugging on, can you please upload the translation log?
It's tough to say without seeing the log first, but this may be related to a similar issue that is currently being looked into where the translation in FME 2018.1 is failing due to a bad feature or invalid date being read in from an Access Database. This is likely why you are able to read the first 100 features (other tables are likely unaffected by this).
Find attached the Log file generated in the Debug method as suggested test.zip
+2- Contributor
bharat wrote:
Find attached the Log file generated in the Debug method as suggested test.zip
Hi @bb,
Thank you for providing that!
It appears you have come across the same issue that is currently being worked on (FMEENGINE-59331). I will be sure to update this post as soon as the fix is available for download; however, if you would also like to be notified by email, please let me know so I can create a case on your behalf and add you to the contact list for this.
In the meantime, it is recommended to run this workspace in FME 2017.0.
Note: if you need to run the translation in FME 2018.1, the Microsoft Access (JDBC) Reader will work as it is not impacted by this issue; however, the jdbc reader will not read features in as fast as the Microsoft Access reader.
chrisatsafe wrote:
Hi @bb,
Thank you for providing that!
It appears you have come across the same issue that is currently being worked on (FMEENGINE-59331). I will be sure to update this post as soon as the fix is available for download; however, if you would also like to be notified by email, please let me know so I can create a case on your behalf and add you to the contact list for this.
In the meantime, it is recommended to run this workspace in FME 2017.0.
Note: if you need to run the translation in FME 2018.1, the Microsoft Access (JDBC) Reader will work as it is not impacted by this issue; however, the jdbc reader will not read features in as fast as the Microsoft Access reader.
Thanks @chrisatsafe I will execute the Workbench in 2017. Will wait to hear from you on this issue, once it is resolved. Thanks once again.
+2- Contributor
Hi @bb,
I’m pleased to let you know that a recent update to FME has resolved this issue!
You will find the update in the latest FME 2019.0 build (19238+) which is available on the Downloads Page. This update is also available on our Past Downloads Page for FME 2018.1 (build 18592+).
Thank you for your patience as we worked to resolve this issue. We appreciate your involvement in helping us make FME even better!
+8- Contributor
Hi @chrisatsafe,
This is to inform you that I still see the same error in 2019.2 (Build 19801) when tried to convert from Epoch(in milliseconds) to ISODateTime using DateTimeConverter.
chrisatsafe wrote:
Hi @bb,
I’m pleased to let you know that a recent update to FME has resolved this issue!
You will find the update in the latest FME 2019.0 build (19238+) which is available on the Downloads Page. This update is also available on our Past Downloads Page for FME 2018.1 (build 18592+).
Thank you for your patience as we worked to resolve this issue. We appreciate your involvement in helping us make FME even better!
@chrisatsafe, I am experiencing the same issue as @fmeuser_gc in the comment above. I am running 2019.2 and receive the following error: DateTimeConverter: The epoch time is out of range. Please ensure it is specified in seconds, and not in milliseconds or microseconds
+31- Influencer
jasonschroeder wrote:
@chrisatsafe, I am experiencing the same issue as @fmeuser_gc in the comment above. I am running 2019.2 and receive the following error: DateTimeConverter: The epoch time is out of range. Please ensure it is specified in seconds, and not in milliseconds or microseconds
Is your epoch time in seconds not milliseconds? Often it would be provided as milliseconds so it is necessary to divide by 1000 prior to conversion in FME
ebygomm wrote:
Is your epoch time in seconds not milliseconds? Often it would be provided as milliseconds so it is necessary to divide by 1000 prior to conversion in FME
My time is provided in milliseconds from ArcGIS Online, so this is a common format. The workaround is to divide by 1,000, although I would like to see this fixed for future users who will see this error and for simplification of workflow.
+31- Influencer
jasonschroeder wrote:
My time is provided in milliseconds from ArcGIS Online, so this is a common format. The workaround is to divide by 1,000, although I would like to see this fixed for future users who will see this error and for simplification of workflow.
Probably something to suggest as an idea in that case
ebygomm wrote:
Probably something to suggest as an idea in that case
I was commenting because @chrisatsafe mentioned that this was fixed in 2019.0. Perhaps I misunderstood, but from my perspective, it appears that the transformer may have a bug that does not recognize milliseconds and it appears he is already familiar with this issue.
+2- Contributor
jasonschroeder wrote:
I was commenting because @chrisatsafe mentioned that this was fixed in 2019.0. Perhaps I misunderstood, but from my perspective, it appears that the transformer may have a bug that does not recognize milliseconds and it appears he is already familiar with this issue.
Thanks for the follow up @jasonschroeder. Are you able to share your log/workspace? If so, please file a case so we can further investigate this issue and reference FMEENGINE-59331 so we can compare the error that you are seeing with the resolved issue. It's possible that this may be a separate (but similar) issue.
chrisatsafe wrote:
Thanks for the follow up @jasonschroeder. Are you able to share your log/workspace? If so, please file a case so we can further investigate this issue and reference FMEENGINE-59331 so we can compare the error that you are seeing with the resolved issue. It's possible that this may be a separate (but similar) issue.
@chrisatsafe, thank you. I submitted case:
C154918The FME format flags are derived from a blend of flags used for date formatting in various languages, mostly C++, TCL and Python. Epoch seconds are consistently represented as %s.
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.