Hi,
I have been tasked to migrate our CE10 implementation (some 300+ reports) to BOXI R2 running on MS Server 2003. We chosen to implement the Enterpise Server in Java (Jakarta Tomcat) as we may be moving to a non-MS platform at some point in the future.
Part of my remit is to introduce what we call dynamic parameters (I think this is what would be known as a "Dynamic List of Values for Parameters" in BOBJ speak.)
AFAIK, I have two options; either use the standard Crystal XI functionality or further customise the Java/JSPs on the Enterprise server. These Java/JSP has already been modified to try and replicate the very heavy customisation that we carried out to the CSP pages in CE10. Unfortunately, this was carried out by another developer who we can no longer use and I have no JSP/Java knowledge. Also, I am not allowed to use any additional 3rd Party software.
So I guess my preferred option is to try and use any functionality in Crystal X1 to achieve this objective.
From other threads on this forum, I have discovered the "Add Command" functionality under Database Expert and how to relate these "commands" to a Parameter. This does allow me to acheive Dynamic Parameters but there is still a very signifcant problem.
Many of threads that I have read seem to advise NOT to link this "command" to the main report "table" in the DB Expert Links tab. However, whether I link them or not, Crystal treats the situation as a mutiple DataSource. This works fine EXCEPT all the filtering is now carried out on the reports server, rather than being passed down to the database server.
Now, many of our main report tables are actually views within the Oracle/JDEdwards(JDE) Environment - and the report accesses this "view/table" through the JDE ODA drivered ODBC connection.
(JDE allows you to create a view in the underlying Oracle DB and then apply a "wrapper" around it, within JDE, so that this view then appears as table when accessed through the ODA/OBBC interface. This approach allows us to apply security and formatting constraints on the data so we cannot now deviate from this method.)
Unfortunately many of our report "views" are very complex, accessing mutiple very large tables. Also the data structures within the JDE database make for very poor joins between the core tables which further reduces the efficiency of these views.
When the report filters are passed back into the database server, the performance of the views is acceptable. However, now that the entire view is being dragged back to the report and then only filtered there, the performance is abyssmal.
So, is there any way of using "commands" without Crystal perceiving this situation as "Mutiple Datasource"? Alternatively, is there any other way to force Crystal to pass all the filters to the DB server, despite it being a "Mutiple Datasource" report? If neither of these options can be acheived, is there any other way I can achieve Dynamic Parameters, subject to the constraints I have detailed above?
Many thanks for any information you can provide.
Regards,
Harry Haines
Reports Analyst.
I have been tasked to migrate our CE10 implementation (some 300+ reports) to BOXI R2 running on MS Server 2003. We chosen to implement the Enterpise Server in Java (Jakarta Tomcat) as we may be moving to a non-MS platform at some point in the future.
Part of my remit is to introduce what we call dynamic parameters (I think this is what would be known as a "Dynamic List of Values for Parameters" in BOBJ speak.)
AFAIK, I have two options; either use the standard Crystal XI functionality or further customise the Java/JSPs on the Enterprise server. These Java/JSP has already been modified to try and replicate the very heavy customisation that we carried out to the CSP pages in CE10. Unfortunately, this was carried out by another developer who we can no longer use and I have no JSP/Java knowledge. Also, I am not allowed to use any additional 3rd Party software.
So I guess my preferred option is to try and use any functionality in Crystal X1 to achieve this objective.
From other threads on this forum, I have discovered the "Add Command" functionality under Database Expert and how to relate these "commands" to a Parameter. This does allow me to acheive Dynamic Parameters but there is still a very signifcant problem.
Many of threads that I have read seem to advise NOT to link this "command" to the main report "table" in the DB Expert Links tab. However, whether I link them or not, Crystal treats the situation as a mutiple DataSource. This works fine EXCEPT all the filtering is now carried out on the reports server, rather than being passed down to the database server.
Now, many of our main report tables are actually views within the Oracle/JDEdwards(JDE) Environment - and the report accesses this "view/table" through the JDE ODA drivered ODBC connection.
(JDE allows you to create a view in the underlying Oracle DB and then apply a "wrapper" around it, within JDE, so that this view then appears as table when accessed through the ODA/OBBC interface. This approach allows us to apply security and formatting constraints on the data so we cannot now deviate from this method.)
Unfortunately many of our report "views" are very complex, accessing mutiple very large tables. Also the data structures within the JDE database make for very poor joins between the core tables which further reduces the efficiency of these views.
When the report filters are passed back into the database server, the performance of the views is acceptable. However, now that the entire view is being dragged back to the report and then only filtered there, the performance is abyssmal.
So, is there any way of using "commands" without Crystal perceiving this situation as "Mutiple Datasource"? Alternatively, is there any other way to force Crystal to pass all the filters to the DB server, despite it being a "Mutiple Datasource" report? If neither of these options can be acheived, is there any other way I can achieve Dynamic Parameters, subject to the constraints I have detailed above?
Many thanks for any information you can provide.
Regards,
Harry Haines
Reports Analyst.