I'm not sure if this is a Crystal or SQL Server issue but I have approached the problem from both ends to no avail.
I am running Crystal reports that use SQL Server stored procedures as the data source.
I send the date parameters as a string from Crystal, and do a conversion on them in the procedure to datetime.
e.g. CONVERT(DATETIME, @START_DATE)
This is because I don't want the users to have to enter the time component of the date parameter. This all works OK.
The problem I have is when I run a main report that runs subreports that are a mixture of using stored procedures and direct Crystal access to the D/B. Of course, I wish to link to the subreports using only one set of date parameters.
So to link to the reports using Crystal direct access, the parameters have to be setup as type 'date'. However, I can't use this approach for the reports using stored procedures because there is no such data type as 'date' in SQL Server.
I tried to get around the problem by sending the date from the main report as type 'string'....fine for the subreports using stored procedures, but not possible for the others as there is no opportunity to 'cast' the string to a date for the other subreports before thay are run.
I hope I explained this well. At the end of the day, I may have to settle for using two sets of reports..one using stored procedures as access and the other direct Crystal access.
I am running Crystal reports that use SQL Server stored procedures as the data source.
I send the date parameters as a string from Crystal, and do a conversion on them in the procedure to datetime.
e.g. CONVERT(DATETIME, @START_DATE)
This is because I don't want the users to have to enter the time component of the date parameter. This all works OK.
The problem I have is when I run a main report that runs subreports that are a mixture of using stored procedures and direct Crystal access to the D/B. Of course, I wish to link to the subreports using only one set of date parameters.
So to link to the reports using Crystal direct access, the parameters have to be setup as type 'date'. However, I can't use this approach for the reports using stored procedures because there is no such data type as 'date' in SQL Server.
I tried to get around the problem by sending the date from the main report as type 'string'....fine for the subreports using stored procedures, but not possible for the others as there is no opportunity to 'cast' the string to a date for the other subreports before thay are run.
I hope I explained this well. At the end of the day, I may have to settle for using two sets of reports..one using stored procedures as access and the other direct Crystal access.