The current version does support DBExpress. You can use a TSQLClientDataset and connect it to a data pipeline via a datasource, just like you would connect a BDE TTable component to a report.
The problem with that is the TSQLClientDataset is slow and has row limitation problems. Are you planning on support data directly from a TSQLDataSet component. Since the BDE is officially dead, I would think this is a priority!
The problem is that the current report engine requires a multi directional dataset. If you don't want to use the TSQLClientDataset, then you can workaroud it by using an in-memory dataset which supports the TDataset interface for bookmarks and multidirectional traversal. Fill the in-memory dataset with the data from the TSQLDataset and connect it up to a TppDBPipeline. You are basically creating your own version of the TSQLClientDataset functionality, which allows multidirectional traversal of the TSQLDataset. This may or may not be faster than if you used a TSQLClientDataset directly, as we haven't tested this technique.
In addition, we would certainly like to make the engine pass through the dataset once. This would allow the report to not require the use of bookmarks and it wouldn't have to move backwards in the dataset at all to support groups and keep together over page breaks. This is on the ToDo list, but it requires rewriting the entire report engine. One day we would like to implement this feature and add it to ReportBuilder. Thanks for the suggestion!
What about supplying your own buffering (vs relying on TClientDataset). That is the direction access is moving. I believe that is how Crystal does it. Having your own internal format would mean that the engine would never have to be updated as data access technologies change.
TClientDataSet brings a lot to the table. A lot more then you need for a report writer.
Comments
and connect it to a data pipeline via a datasource, just like you would
connect a BDE TTable component to a report.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
limitation problems. Are you planning on support data directly from
a TSQLDataSet component. Since the BDE is officially dead, I would
think this is a priority!
dataset. If you don't want to use the TSQLClientDataset, then you can
workaroud it by using an in-memory dataset which supports the TDataset
interface for bookmarks and multidirectional traversal. Fill the in-memory
dataset with the data from the TSQLDataset and connect it up to a
TppDBPipeline. You are basically creating your own version of the
TSQLClientDataset functionality, which allows multidirectional traversal of
the TSQLDataset. This may or may not be faster than if you used a
TSQLClientDataset directly, as we haven't tested this technique.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
dataset once. This would allow the report to not require the use of
bookmarks and it wouldn't have to move backwards in the dataset at all to
support groups and keep together over page breaks. This is on the ToDo list,
but it requires rewriting the entire report engine. One day we would like to
implement this feature and add it to ReportBuilder. Thanks for the
suggestion!
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
That is the direction access is moving. I believe that is how Crystal
does it. Having your own internal format would mean that the engine
would never have to be updated as data access technologies change.
TClientDataSet brings a lot to the table. A lot more then you need for
a report writer.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com