For example, "changing a report at run-time" has all kinds of repercussions. The queries and logic involed with pulling the data from the database efficiently, the way the data gets populated and further modified in the BO, the way it is pulled and shown on the report, etc.

Again, I understand the point of the excersize. Generating reports, by their nature, involves some busy-work and you are trying to avoid that. However, for me, this isn't something where further automation would pay dividends. Obviously, your needs may differ, but the StrataFlix example is a result of our own examinations of how much we could resonably automate versus how much would require developer intervention, and what you see there is effectively where we landed.

For perspective, we also have more than 100 reports in our medical application (108 at the moment, with that number growing every version), but we have followed basically the same process you see in the StrataFlix reports for each one.  Using the custom BBS, you get to inherent all of the basic BO logic, and only have to account for the custom logic that is necessary for each report. Yes, you have to code any custom properties to accomodate the custom logic required by a given report. However, you are going to have to code those custom properties regardless of whether you do it in the development environment, or through some mechanism at runtime.

Let me explain it more clearly.

We are already storing the table fields and their relationships in our database. A class method can take three parameters, an array of tables, an array of the fields that are going to be displayed and the name of a stored procedure. By using the already stored relationship information, our object can automatically figure out which fields should be added to BO and it can automatically add these fields, execute the stored procedure and connect the resulting BO to the custom BBS that can be used for a grid or a report. We would like to write this method but we dont know how to create the BO properties at runtime.

Wouldnt it be simpler to just call this method instead of creating a number of custom BBS and custom BO and adding each one to the project manually?

Could you give a specific example? I.e. "we have two tables, Customer and Employee, with fields x, y, and z. We want to provide parameter Q and have it spit out a BO containing a, b, and c." 

In short, I don't think we have the capability to do exactly what you are looking for currently in the framework, but that is because, to my knowledge, we haven't run accross a definate need for it. Most requirements that hit around this are covered by (manually programmed) custom properties, pseudo BOs, views, or (if you are more worried with development speed than best practices) the ability to directly reference custom columns in a returned datatable (i.e. MyBO.CurrentRow["myColumn"]).

As far as automating the reporting process further, Edhy and Trent have been having a good discussion around possibilities there, and planned future development for StrataFrame in this thread. You may browse through it real quick to see if any of the ideas or points there are hitting home with what you are trying to do.