M
Mario T. Lanza
Greetings,
I have used Crystal for over 5 years now. I have developed a number
of report viewing sub-applications (nothing too extravagant).
Crystal's object model is not developer friendly. Many of you who
debug your Crystal apps in .NET will no doubt have witnessed the
gobbledygook visible when viewing the tree view of the ReportDocument
object.
On issue that I have been unable to resolve FOR SEVERAL YEARS now is
the passing of null parameter values in order to use the default
stored proc values.
For example consider this stored proc's parameter declaration:
CREATE PROCEDURE RptTransactions
@DateFrom as datetime = null,
@DateTo as datetime = null,
@StoreNo as smallint = null,
@EmployeeNo as smallint = null,
@WindowNo as smallint = null,
@DrawerID as int = null,
@CategoryCode as varchar(2) = null,
@KindCode as char(1) = null,
@CheckCashing as bit = 0
AS
My .NET application accepts preconfigured parameter strings like this:
@DateFrom{7/30/2004}@DateTo{8/11/2004}@StoreNo{73}@EmployeeNo{}@WindowNo{}@DrawerID{}@CategoryCode{}@KindCode{}@CheckCashing{}
As you can see a number of the parameters have blank values ("{}")
immediately following. In the cases of these parameters, I pass
"null" (not DBNull.Value -- it throws an exception). Pay special
attention to the @CheckCashing parameter. The idea is that when the
Crystal Report receives null for the @CheckCashing parameter it will
in turn pass the null parameter to the stored
proc which will in turn default it to "0" as indicated for the default
value. This does not happen. It seems I have more problems with
boolean (bit) value parameter passing then with any other kind of
parameter passing.
I have been able to create two workarounds (band-aids that I hope to
properly resolve):
1. I created a function that parses the stored proc called by the
report and determines the default value so that I can apply it
directly to the crystal report.
2. I convert boolean fields to char(1) and pass "Y" or "N".
The funny thing is that this weird bool behavior is inconsistent.
Some of my reports using booleans seem to work just fine. I have
checked the report definitions as well and whether or not these
parameters have default values assigned within the report itself seems
to have no bearing on the outcome.
Any ideas?
I have been working around these issues for some time and I hope to
put them to bed the right way! Thanks for your consideration of this
issue.
Mario T. Lanza
Clarity Information Architecture, Inc.
I have used Crystal for over 5 years now. I have developed a number
of report viewing sub-applications (nothing too extravagant).
Crystal's object model is not developer friendly. Many of you who
debug your Crystal apps in .NET will no doubt have witnessed the
gobbledygook visible when viewing the tree view of the ReportDocument
object.
On issue that I have been unable to resolve FOR SEVERAL YEARS now is
the passing of null parameter values in order to use the default
stored proc values.
For example consider this stored proc's parameter declaration:
CREATE PROCEDURE RptTransactions
@DateFrom as datetime = null,
@DateTo as datetime = null,
@StoreNo as smallint = null,
@EmployeeNo as smallint = null,
@WindowNo as smallint = null,
@DrawerID as int = null,
@CategoryCode as varchar(2) = null,
@KindCode as char(1) = null,
@CheckCashing as bit = 0
AS
My .NET application accepts preconfigured parameter strings like this:
@DateFrom{7/30/2004}@DateTo{8/11/2004}@StoreNo{73}@EmployeeNo{}@WindowNo{}@DrawerID{}@CategoryCode{}@KindCode{}@CheckCashing{}
As you can see a number of the parameters have blank values ("{}")
immediately following. In the cases of these parameters, I pass
"null" (not DBNull.Value -- it throws an exception). Pay special
attention to the @CheckCashing parameter. The idea is that when the
Crystal Report receives null for the @CheckCashing parameter it will
in turn pass the null parameter to the stored
proc which will in turn default it to "0" as indicated for the default
value. This does not happen. It seems I have more problems with
boolean (bit) value parameter passing then with any other kind of
parameter passing.
I have been able to create two workarounds (band-aids that I hope to
properly resolve):
1. I created a function that parses the stored proc called by the
report and determines the default value so that I can apply it
directly to the crystal report.
2. I convert boolean fields to char(1) and pass "Y" or "N".
The funny thing is that this weird bool behavior is inconsistent.
Some of my reports using booleans seem to work just fine. I have
checked the report definitions as well and whether or not these
parameters have default values assigned within the report itself seems
to have no bearing on the outcome.
Any ideas?
I have been working around these issues for some time and I hope to
put them to bed the right way! Thanks for your consideration of this
issue.
Mario T. Lanza
Clarity Information Architecture, Inc.