Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I've been attempting to use the functions ReloadTIme() or now(0) which as far as I can tell are identical, to output the last successful reload time for exception reporting purposes, e.g. to warn users when the data is behind.
In my main qvws, neither function is working. Reloadtime() outputs nothing, while now(0) outputs 'day zero' (30/12/1899). I assume the only difference in outputs it due to their default formatting options.
However, I most certainly have reloaded these files many times. In other existing documents, and in new test documents on the same system (Windows Server 2012 Standard) the functions work just fine:
Testing on a newly created which has never been reloaded or saved, I still get a result for now(0) which equals its creation time, though ReloadTime() is blank:
I guessed reload method could have something to do with it, as the two main documents that don't work (first screenshot above) are running on scheduled reloads. However, testing on other scheduled documents works fine and reload times are correct.
Any ideas? My other thought is that is could be because both documents' scheduled reload happened to fail today (which is why I was looking to add the checks), but if the method doesn't work when the documents fail then it completely defeats the purpose.
Standard schedule, daily reload in this case, on QV Server, no publisher.
I was assuming that would be the behaviour too, so odd it's just blank.
I'll retest a scheduled reload with a deliberate failure forced a bit later and see what the result it. Scheduled reloads on new documents and some existing documents which reload every 5 min are working just fine for both the reloadtime() and now(0) functions.
Has the app ever reloaded successfully?
If you create a blank qvw and do not reload it, then reloadtime() returns blank, but once it has reloaded you see a time.
Mike Swinn wrote:
I've heard that now(1), which is the default functionality of now() can be dangerous as it's the current system time and and refreshes every second or more frequently, so would agree with you there.
I am pretty certain that this caution only applies to the use of now and today in expressions in the front end. There is no such impact in script which executes synchronously so there is no polling involved.
With modern servers, I expect that now(1) on the front end should only have an impact if some complex calculations are being performed on large data sets (based on the value in now?). This caution has been around for years and hardware has improved considerably since then. Personally, I have never seen an issue - but that's just my experience.
Jonathan
Hello MikeSwinn, I'm facing the same issue with QV 11.20.12354.0409 (SR6 I believe) when using -prj folders. Once I delete -prj folders everything works fine. After creating them again reload time is lost. Seems like a bug to me.
Interesting, that would explain the inconsistent behaviour between files. Agreed it's a bug.
Hi,
I found same behavior on customer's Qlik document and I solved changing TimestampFormat system variable.
There was a mistake on TimestampFormat mask.
Regards,
Ely
It's been some time but now I remembered, my issue was fixed I think with SR10.