The problem with this type of thing is that the data for the "big picture" is not simple to get to. You can run queries in Query Builder to get the scheduling information, but to get the details about the inner workings of each report you have to open the report (whether in Crystal itself or in a program using the SDK) to get to it - there's no way to do that from Query Builder.
In terms of organizing your reports, you may want to look at putting the information into a database instead of using a spreadsheet. This can get somewhat complex, but the program I was working on that I never finished had the following tables:
Report - contained base information about a report - title, description, path in Infoview, etc. Key field is ID which is the SI_ID value from BO - this is used to link together all of the report information in various tables.
ReportTables - ID, table name, database info.
ReportParams - Information about the parameters and default values for each report.
ScheduleInfo - Various fields for info about the recurring schedules. Different types of schedules (daily, weekly, monthly, calendar, event) can require different different fields to store their details. This also includes info about the output type and destination for each schedule. It also contains a Instance_ID field which is the SI_ID for the recurring schedule. This is used to link to the next couple of tables.
SchedEmails - Instance_ID and Email Address (individual - broken out from the list of email addresses when the destination is email.
SchedParams - Instance_ID, ParamName, ParamType, ValueStart, ValueEnd. For single value params, the value is in ValueStart, range params need both value fields.
There may be a couple of other tables, but this is what I can remember off the top of my head. The structure makes it easy to run reports off of this data to get some or all of it as needed.
-Dell
IP Logged
