You are viewing limited content. For full access, please sign in.

Question

Question

Audit Trail - Date Range by Age is not what I think it is

asked on October 8, 2020

To me a date range of 90 days ago - Now would mean 90 days from the computer clock.

Why is it this crazy time range?

This has nothing to do with the previous post I made which was another system. This is another new install and I am just trying to do a date range by age. I feel this system is talking a different language than I am. My definitions of between and ago are different.

0 0

Replies

replied on October 8, 2020

Can you look on the configuration page and see which logs are loaded? Audit Trail loads complete logs in the database, so depending on the logs roll over, the data available may start a bit before the specified range.

0 0
replied on October 9, 2020 Show version history

I thought the data was extracted from the text files into my SQL database where it is then filtered by my specified date range.

Here are the files but I don't really see what it has to do with my date range.

I am asking it to show data from "90 days ago - Now", but it is giving me a range of years all the way back to 2017 starting with May of 2020. I don't understand the logic, how is that 90 day ago to Now?

I can't work with Audit trail on any 10.4 systems any longer due to the fact that the date range it gives me never matches what I ask for. Only 1 remaining 10.3 version out there continues to work.

0 0
replied on October 12, 2020

That looks like a screenshot from Windows Explorer not from the audit reporter's configuration page. I'm only guessing since the column header is not present, but Dev.log was created on 5/7/2020 and contains information from that date on. So when you asked for "last 90 days", you get that entire log loaded in the database.

0 0
replied on October 12, 2020

How would I be able to define a date range if I am restricted by the size of the log files? Do I need to tell the system to roll over to a new log daily? I don't understand the correlation between log file size and date ranges. From my perspective as a user, I get an option to define a date range on the front end, and I expect to see data for the range I defined.

0 0
replied on October 12, 2020

Your screenshot shows 3 logs from 2017 and one from this year. Like I said, it's not clear to me what date you're showing there, so I can't give you a better guess at what data is in Dev.log.

When you ask for a date range, the server inventories existing logs and loads the ones that cover the requested range in the database for reporting.

0 0
replied on October 12, 2020

But where does the range come in.

For example I said 90 days ago to now. It pulled all 4 logs, which is fine if it want's to do that. But now that it has the data in the database, why am I seeing data for May of this year all the way back to 2017.

I didn't show the bottom of the date range in my screenshot, because even the top of it is enough to show that it doesn't fall in the range I defined.

Regardless of how the system works on the backend, the range should match what is defined.

0 0
replied on October 12, 2020

Do you have a screenshot of the configuration page? I'm not sure what you mean by "it pulled all 4 logs".

0 0
replied on October 12, 2020

A screenshot of the part that shows the logs? My screenshot in the original post clearly shows the insanity. There is no way 90 Days Ago - Now includes May when it is October.

Here is another example where I was working with support trying to view data, they used a range in the year of 2017 to pull up data in the year 2015. This makes entirely no sense, and even they don't understand why 2017 should not equal 2015. I still can't get any information on them of how they knew to pull the 2017 range to get 2015. It is JUST not logical to say that 10/29/2015 IS BETWEEN 1/2/2017 and 12/29/2017. How am I the only one who agrees with this statement?

0 0
replied on October 12, 2020

And here is the full configuration page.

 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.