Are SSRS parameters fixed while generating a report? - reporting-services

Question

I have been using the following code within my SQL queries:
DECLARE #CurrentDate DateTime = Getdate()
I then reference #CurrentDate instead of using the Getdate() function multiple times within the same query. This is useful because the value of #CurrentDate doesn't change during execution of the query.
However, I have started converting some of these variables to parameters set by SSRS. This allows the user to change the parameter #CurrentDate which is useful for various reasons. Typically the default value is set to "=Now()" or some expression containing the Now() function.
At what stage are these parameters calculated and is there a "correct" way to calculate them if I want parameters to be consistent with one another?
I'm trying to figure out if I should have one parameter for the current date and then reference that in the calculation of my other parameters or if this will produce the same inconsistencies (or worse inconsistencies) as simply using Now() within the expression for each parameter.

Answer 1

It all depends on what you mean by "consistent". Take these two scripts for example:
--Method #1
UPDATE tracker.shipment SET delivery_date = GETDATE() WHERE delivery_id = 1;
WAITFOR DELAY '00:00:01';
UPDATE tracker.shipment SET delivery_date = GETDATE() WHERE delivery_id = 2;
--Method #2
DECLARE #current_date DATETIME = GETDATE();
UPDATE tracker.shipment SET delivery_date = #current_date WHERE delivery_id = 1;
WAITFOR DELAY '00:00:01';
UPDATE tracker.shipment SET delivery_date = #current_date WHERE delivery_id = 2;
This is a pseudo script to update a tracking system to show when delivery was made. I would argue that the first version is more "consistent" as it records when the update was actually made, and not an arbitrary date/ time from when the stored procedure was first entered.
Let's pretend that there's another system constantly checking for delivery items that have a delivery date added, then makes the actual delivery, or that the code immediately before each delivery update does something to trigger the actual delivery. In this case it would be much less consistent to use the second method, as this would record deliveries as being made for some time in the past, before they actually were delivered.
As far as I am aware the parameter sent by SSRS will be evaluated to determine the server time on the reporting server at the point where the user clicks the "View Report" button. So every parameter that has Now() will end up with the same date time, but this might be slightly out from the SQL Server if your servers aren't exactly in synch.
Does this actually matter? Well that depends entirely on what you are doing with the date/ time you are passed I guess. When your users enter a custom date/ time are they entering a date or a full date/ time? I imagine they only enter a date, so this is automatically converted to having a 00:00:00.00 time component?
Basically I would need more context to be able to give a fuller answer to this.

Answer 2

Just create a datetime SSRS parameter and set the default value to NOW(). Then it will assume everything, but users can opt for a different date. Note also that SSRS uses DATETIME parameters, but for a lot of my reports I actually use a string parameter field which I CAST to DATE to avoid losing data between hours that the user isn't expecing:
WHERE CAST(StartDate AS DATE) > CAST(#StartDateParam AS DATE)