What’s the current situation with DA and ReportBuilder? Is there any way of integrating the two to get RB to perform data access via DA?

I found a blog containing a partial solution from back in 2008 but it’s incomplete and not even sure if it would work with the latest versions of RB and DA.

Wondering if any further work has been done on this or whether I’m on a hiding to nothing trying to get this to work?


as I see, we hadn’t any issues with ReportBuilder.
I’ve attached old DA4 sample - Report Builder (60.3 KB)

Note: this sample wasn’t modified for ages and may require manual changes that described here.

The problem as I see it is that RB wants a direct database connection. The old semi-solution I found involved writing a custom DADE driver for RB to work via Data Abstract.

I’ll have a look at the example, thanks.


this sample uses

  object ppReport: TppDBPipeline
    DataSource = dsReport
    UserName = 'Pipeline'
    Left = 68
    Top = 117
  object dsReport: TDADataSource
    DataTable = dtReport
    Left = 22
    Top = 117

as you can see, TppDBPipeline references to usual TDADataSource

I’ve used Reportbuilder for years in DA servers. I did originally look at writing a custom DADE driver but in the end I found the simplest thing was simply to use the direct database connection at the server side, I simply have on the Delphi side DA server a service that is for RB, and I change the data pipeline for RB to point to the relevant database (in my case it’s either DBISAM or Postgresql though I’ve also used it with mySQL and SQL Server), which then fetches the requested report, populates the parameters and sends the report back to the client as a PDF.


I could actually get away with a direct database connection server-side, in the short-term at least.

Are you using RB Server edition (we only have Enterprise)? How are you feeding the PDFs back to the client?

Also, surely the report designer still has to run client-side, which also requires access to the database for previewing/testing?

No, we only have the enterprise too (actually quite old now, version 16, as we haven’t moved on from XE8), so effectively I’ve created our own version of the server version and it works very well.

In the DA service that does the reporting, we just call a GetReport method that we pass the parameters for the report and the ID of the report itself (the client receives a list of available reports when the user logs in) then we return the report as a TROBinaryMemoryStream. I’ve just looked, and actually we create it as an ArchiveFile which is what is passed back to the client, which uses the RB report viewer to display it then the user can save it as PDF or whatever as required. We have another function that does similar that returns the PDF directly from the server, which is for mobile devices to view them (created using Fire so no RB on iOS :grinning:)

Well, we don’t let the users create reports, so the reportbuilder app I created which is only used by the office staff, to update the reports in the DB, also talks directly to the database so that’s not really an issue for us.

Thanks, it sounds like you’re using much the same technique as the demo that Evgeny posted above, which certainly works for me.

Unfortunately we need to allow our users to use the report designer which is more of an issue so I’m looking at the DADE option again.


if you need TCustomConnection object, you can get it with the IDAConnectionObjectAccess interface from the IDAConnection interface.

1 Like

Sorry but I have no idea what that means.

I’ve never looked at the RB DADE stuff. I’ve tried looking at their examples but can’t make head nor tails of it.

I’ve looked at the partial solution I found here:

I understand how the DA side of this is supposed to work, providing a service which can execute the arbitrary SQL generated by RB on the client but have no idea how to get RB to use it on the client side.

I am utterly and completely stuck here and can’t believe there isn’t full support for RB via DA. The example above merely executes reports on the server and sends the result to the client which is useless if you need to have report designing/editing functionality on the client.

Does anyone have any ideas how to complete the above code (people who post incomplete solutions should be shot) or any other ideas on how to get this to work?

i just use RB with the standard tDaDatasource…

That works for folders and items so I can successfully browse my folder structure and see reports in the browser, but when I try to run or preview a report, it does work.

In this case RB wants to use it’s own SQL against the database connection which is where everything falls apart.


we are working on DA SQL feature for Delphi, but this issue has low priority so I can’t say any term when it will be done.

you mean that you let your endusers select the tables etc they want to produce whatever report they want?
we don’t have that, we do provide 'dataset’s that they can use to alter existing reports…
i remember once having a dade driver also but can’t remember why we abandoned it

we had a RBservice for DA ion which we implemented
procedure GetTableNames(out TableNames: String);
procedure GetFieldNames(const TableName: String; out FieldNames: String);
function GetData(const SQL: String; const TableName: String;
const LoadAll: Boolean): Binary;
function GetSchema(const SQL: String; const TableName: String;
const LoadAll: Boolean): Binary;

and hacked it client side into the unit daDataAbstract
that’s also probably why we abandoned it


in general, you could just grab standard Schema and parse it on client-side for RB compatible source …

I found the same info about the GetTableNames, GetData, GetSchema approach with the daDataAbstract.pas file implementing a custom DADE driver on the client.

I got it to compile but couldn’t work out how to actually get RB to even use it. Have raised a support issue about that with Digital Metaphors but not holding out much hope.

This is more on them than RO - they’ve provided a DADE system for writing custom data drivers but have completely failed to actually provide a working, supported one for DA.