You are not logged in.
Pages: 1
Hi,
I am using two date parameters for a dynamic list report (parameters are used to retrieve results from date range from-to).
Parameter Mode: Date, no default values used.
Using the parameters in sql like this:
((${StartDate} IS NULL) OR (CAST(${StartDate} AS DATE) <= CAST(Ata AS DATE)))
AND
((${EndDate} IS NULL) OR (CAST(${EndDate} AS DATE) >= CAST(Ata AS DATE))) Steps:
1. Run variant, enter start and end dates, e.g. 01/01/2022 - 31/12/2022 - returned record count: 11897 (correct)
2. Save variant (dates get saved with the variant) - run the report again - returned record count: 11890 (not correct)
3. Delete saved dates and enter same dates again - run the report again - returned record count: 11890 (not correct)
4. Enter some other random dates, run the report
5. Enter again the required dates 01/01/2022 - 31/12/2022 - returned record count: 11897 (correct)
Any idea what causes the changed results here?
Tried it several times, always the same (difference in) results.
Is it possible that parameter value that gets sent to db is different when parameter is saved with variant compared to entering it manually each time?
If that is the case, what is the solution?
Is there a setting that would prevent users from saving parameter value when saving the variant?
Last edited by nsarlija (2023-08-24 14:11:08)
Offline
Hi nsarlija,
what DB exactly are you using on this report? And what RS version exactly are you using ?
Regards,
Eduardo
Offline
Hi Eduardo,
DB is SQL Server (Microsoft SQL Server 2019 (RTM-GDR) (KB4583458) - 15.0.2080.9 (X64)
Nov 6 2020 16:50:01
Standard Edition (64-bit))
and RS is RS4.2.0-6072 (2022-08-22-10-22-31) Community edition
Offline
Hi nsarlija,
can you pls try with the latest RS 4.6.1 ? You can install it (test installation) quickly by the Installer https://reportserver.net/de/download/ , just with some "next", "next" buttons in a Windows machine.
Regards,
Eduardo
Offline
Hi Eduardo,
I tried what you suggested, and the issue is not occurring on the latest version.
I tried to further troubleshoot the issue, and still not sure what exactly is the cause.
The issue persists when recreating variants.
It seems to be related with date handling, e.g., in one case record from 31-12-2021 is taken into consideration when it should be excluded.
Apart from upgrading, do you have any other suggestion how to work around this issue on the current version?
Offline
Hi nsarlija,
if this does not happen in the newest version, this was a bug and was corrected in newer versions.
Pls upgrade to the newest version.
Regards,
Eduardo
Offline
Hi All,
I did a bit more in depth testing on versions: RS4.6.1-6094, RS4.6.1-6100, RS4.6.1-6102.
Issue: The SAVE AS variant process moves the Calendar Control date back 1 day during the SAVE AS variant step.
Example: User enters DEC 1, 2023 in calendar control, and during the SAVE AS variant process, after saving, the calendar control shows NOV 30, 2023 in some cases, depending on the user local desktop time zone, and possibly the users local time, although I did not check to the testing time level, so if you get slightly different results, it may be due to the local time when doing the testing.
Note: If you update the calendar control date again to DEC 1, 2023 and SAVE over the original variant, the date saves with user entered value as expected.
Test case: SAVE AS VARIANT calendar check:
1. I set my desktop time zone to: Mumbai - Current time in India 1:00AM
2. I created a dynamic list report called: Calendar Check
Note: You do not need to add the parameter ${p_start_date} into the actual query for the tests below, only create the calendar parameter object in parameters so it will prompt when the report is run.
Report Query:
If using Postgres:
select current_date as dt
If using Oracle: select sysdate as dt from dual
Select Parameters tab:
Add a Calendar Control parameter called: Start Date
- Execute initial report with your desktop time zone as Mumbai
- Change date in calendar control to DEC 1, 2023
- Select SAVE AS Variant with name: T1
- T1 should save correctly with date as DEC 1, 2023.
- Without closing browser, change your windows time zone to Brasilia
- Change Date in calendar control to DEC 1, 2023
- Select SAVE AS Variant with name: T2
- T2 should save correctly with date as DEC 1, 2023.
- Without closing browser, change your windows time zone to Eastern Time US
- Change Date in calendar control to DEC 1, 2023
- Select SAVE AS Variant with name: T3
- T3 should save correctly with date as DEC 1, 2023.
- Without closing browser, change your windows time zone to Central Time US
- Change Date in calendar control to DEC 1, 2023
- Select SAVE AS Variant with name: T4
- T4 SAVES INCORRECTLY moving saved date to NOV 30, 2023.
- Without closing browser, change your windows time zone to Pacific Time US
- Change Date in calendar control to DEC 1, 2023
- Select SAVE AS Variant with name: T5
- T5 SAVES INCORRECTLY moving saved date to NOV 30, 2023.
** All of these time zones were checked and SAVE INCORRECTLY currently: Central America, US Central Time Zone, US Mountain Time Zone, Pacific Time Zone (US and Canada) and Hawaii Time Zone.
The SAVE AS variant moves the date back 1 day to NOV 30, 2023 in the calendar control.
** Other time zones were not checked**
Hope this helps find a solution for a future update.
Last edited by eeuser01 (2023-12-21 20:23:31)
Offline
Hi eeuser01,
Thanks for your help.
I did not understand tough, what did you mean by date saves incorrectly?
I mean, are you able to see it on the screen, that the actual date in the control has changed, or is there another way that you tested this?
That was my presumption as well, but I was not able to actually see it anywhere.
I am still having issues with this.
After upgrade, reports from previous version were imported (with variants) and they are still behaving as before, issue with dates persists.
The only way around this (that I have found so far) is to build same variant from scratch on the new version.
Only in that case problem seems to go away.
But this involves a lot of work, so appreciate if there are some other ideas I could try.
@eduardo, do you know where the issue here is exactly?
Could it be fixed?
Offline
Hi,
thanks for the information and the test cases. We raised RS-8108 for investigating.
Regards,
Eduardo
Offline
Pages: 1