We are in process of converting one of our applications to Application Role
security, and the last major obstacle to overcome is reporting services
(currently SQL2K, upgrading to 2K5 in 2 months, if it matters). From reading
the (very sparse) documentation, it should be possible to use a Custom Data
Extension (CDE) to allow this functionality.

A previous developer had found some sample code and threw together a
non-working skeleton, and it got passed to me to make it work.

I have inspected the code and see that it is implementing the correct
interfaces, and have written several NUnit tests to inspect that the compiled
CDE actually does what I expect it to. I have added it to the report
designer and the reporting server, and it can be selected from the report
designer "Type" drop down when creating a shared data source. However, when
I select the Shared Data Source that uses the CDE for a report and go to the
"Data" tab in the designer, I get the following error: "A connection cannot
be made to the database. Set and test the connection string." (The NUnit
tests do show that is does successfully connect when used.)

How do I troubleshoot this? Is there checklist of things that I need to
have done inside my CDE to make it work? (Beyond just implementing all the
interfaces) Are there attributes I need to add to the CDE to allow Reporting
services to work?

Re: Troubleshooting a Custom Data Extension by Lance

Lance
Wed Aug 09 15:23:05 CDT 2006

I am having this exact same problem. Does your error message also say
"the data processing extension (what you named it) could not be loaded.
Check RSReportDesigner.config" ?

I believe that this (my problem at the least) is caused by missing some
step when modifying the config files. Does anyone know where we can
find the full correct way of deploying our data processing extensions??

Lance M.

SvdSinner wrote:
> We are in process of converting one of our applications to Application Role
> security, and the last major obstacle to overcome is reporting services
> (currently SQL2K, upgrading to 2K5 in 2 months, if it matters). From reading
> the (very sparse) documentation, it should be possible to use a Custom Data
> Extension (CDE) to allow this functionality.
>
> A previous developer had found some sample code and threw together a
> non-working skeleton, and it got passed to me to make it work.
>
> I have inspected the code and see that it is implementing the correct
> interfaces, and have written several NUnit tests to inspect that the compiled
> CDE actually does what I expect it to. I have added it to the report
> designer and the reporting server, and it can be selected from the report
> designer "Type" drop down when creating a shared data source. However, when
> I select the Shared Data Source that uses the CDE for a report and go to the
> "Data" tab in the designer, I get the following error: "A connection cannot
> be made to the database. Set and test the connection string." (The NUnit
> tests do show that is does successfully connect when used.)
>
> How do I troubleshoot this? Is there checklist of things that I need to
> have done inside my CDE to make it work? (Beyond just implementing all the
> interfaces) Are there attributes I need to add to the CDE to allow Reporting
> services to work?


Re: Troubleshooting a Custom Data Extension by Lance

Lance
Fri Aug 11 08:54:34 CDT 2006

I managed to solve my problem. What had happened was I had included an
old version of Microsoft.ReportingServices.Interfaces.dll into my
project. You have to make sure you use the one that is stored in the
ReportServer\bin directory. If your code throws any errors when
compiling -as I found out mine did when the two versions got tested
together at the same time - your assembly will not be loaded onto the
report server, and it will throw that generic error (check
RSReportDesigner.config). I lost so much time because I had used the
old version of Microsoft.ReportingServices.Interfaces.dll that came
with the FSIDataExtension example XD. I hope this helps!

Lance M.

Lance M wrote:
> I am having this exact same problem. Does your error message also say
> "the data processing extension (what you named it) could not be loaded.
> Check RSReportDesigner.config" ?
>
> I believe that this (my problem at the least) is caused by missing some
> step when modifying the config files. Does anyone know where we can
> find the full correct way of deploying our data processing extensions??
>
> Lance M.
>
> SvdSinner wrote:
> > We are in process of converting one of our applications to Application Role
> > security, and the last major obstacle to overcome is reporting services
> > (currently SQL2K, upgrading to 2K5 in 2 months, if it matters). From reading
> > the (very sparse) documentation, it should be possible to use a Custom Data
> > Extension (CDE) to allow this functionality.
> >
> > A previous developer had found some sample code and threw together a
> > non-working skeleton, and it got passed to me to make it work.
> >
> > I have inspected the code and see that it is implementing the correct
> > interfaces, and have written several NUnit tests to inspect that the compiled
> > CDE actually does what I expect it to. I have added it to the report
> > designer and the reporting server, and it can be selected from the report
> > designer "Type" drop down when creating a shared data source. However, when
> > I select the Shared Data Source that uses the CDE for a report and go to the
> > "Data" tab in the designer, I get the following error: "A connection cannot
> > be made to the database. Set and test the connection string." (The NUnit
> > tests do show that is does successfully connect when used.)
> >
> > How do I troubleshoot this? Is there checklist of things that I need to
> > have done inside my CDE to make it work? (Beyond just implementing all the
> > interfaces) Are there attributes I need to add to the CDE to allow Reporting
> > services to work?


Re: Troubleshooting a Custom Data Extension by SvdSinner

SvdSinner
Wed Aug 16 10:22:01 CDT 2006

No, the .dll is compiling just fine. I've tested it heavily with unit test
to make sure that when the methods I created do return what I think they
should.