Bug(?) with pipelines

rbuser

Hi list,

I'm having a problem with data pipelines.
I created a report and transferred that report to another computer. When I
then got into the data view and click on the preview button of the
pipeline I get more rows than on my system.

The database and all other parameters are exactly the same!

When I then just alter the pipeline, e.g. add or remove a column, the
result is the same as on my system.

I'm using version 10.06 of ReportBuilder. Is this a bug in the
ReportBuilder I'm using (fixed with 10.09 maybe)?



--- posted by geoForum on http://delphi.newswhat.com

rbuser

Hi again!

I just accessed (just opened and closed all pipelines; didn't change
anything) all pipelines on the target system and saved the report.
It now works!

Converting both reports to text files the only differences I got are the
following:

Created on an MSSQL-Server (didn't work on the target):

object TppMasterFieldLink
MasterFieldName = XXX
GuidCollationType = gcMSSQLServer

DetailFieldName = XXX
DetailSortOrder = soAscending
end

changed on the target (Interbase):

object TppMasterFieldLink
MasterFieldName = XXX
CollationType = ctASCII
GuidCollationType = gcString
DetailFieldName = XXX
DetailSortOrder = soAscending
end

And for the SQL the differences are the following:

MS-SQL:

object daSQL14: TdaSQL
CollationType = ctASCII
DatabaseName = XXX
DatabaseType = dtInterBase
DataPipelineName = XXX
[...]

Interbase:

object daSQL14: TdaSQL
GuidCollationType = gcMSSQLServer
DatabaseName = XXX
DatabaseType = dtMSSQLServer
DataPipelineName = XXX
[...]

Why should this affect the results?

Kind regards,
Christoph



--- posted by geoForum on http://delphi.newswhat.com

rbuser

Does anyone read this list?

We're having a serious problem here, since reports generated under
Interbase won't work any more if you change something in the SQL objects
using the MS SQL server!
Our customers have the MS SQL Server, Interbase, Oracle and others and
those reports do not work anymore!

We tried setting the DatabaseType of the daSQL object to the corresponding
database (dtOracle, dtMSSQLServer, dtInterbase) which kind of worked, for
reports created by the MS SQL server, but reports created by Interbase now
result in error messages because "TABLE_1" can't be found on Oracle or MS
SQL server.

The only option we have currently is not using the ReportBuilder any more.
Do you have any suggestions?

Regards,
Christoph



--- posted by geoForum on http://delphi.newswhat.com

nardmoseley

Please configure your newsreader to post using your name. Currently it
displays
Christoph _baka0815_ Schwerdtfeger.

This question should be posted to the DADE newsgroup. Until this post, I had
no clue what you were trying to accomplish. And even now I do not have all
the details.

What type of data connectivity are you using to target all of these
databases? Prehaps dbExpress?

Please provide more details about what you are trying to accomplish.

--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

rbuser

Hi Nard!

Well, I'm sorry for my harsh tone!

The problem we're having is that we need to support multiple databases.

When we create a report using an InterBase server (and configuring the
queries in the report itself, that's what I'm referring to as
datapipelines here) we have no problems using this report on other
databases. The same goes for reports designed with Oracle or the MS SQL
Server.

The problems start when we try to change a report using a different
database connection than it was originally designed with.
If we change a reports with the MS SQL server which was designed using an
InterBase connection f.e.
Trying to change those query-objects results in errors and possibly kills
the report.

The solution we found for us is to show a warning if we try to change a
report using a different database than it was previously created with and
then switch databases to alter that report.

We're using the BDE actually...

Kind regards,
Christoph



--- posted by geoForum on http://delphi.newswhat.com

nardmoseley

The Designer.DataSettings get assigned to the QueryDataView's internal
TdaSQL object when the query is first created. You need to assign an
event-handler to the Report.Template.OnLoadEnd event to iterate over the
dataviews and update the TdaSQL properties such as DatabaseName,
DatabaseType, SQLType, etc.

This example shows how to iterate over the dataviews and update them.

www.digital-metaphors.com/tips/DadeUpdateDatabaseName.zip


--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

rbuser

Hi Nard,

thanks for the answer and for the example.


We tried that before. Just setting the database type caused us even more
trouble. We got messages about identifiers which couldn't be bound
(InterBase uses alias' for every table like "table_1" which confuses other
database systems).
It works okay as long as we do not change the report.

It wasn't easy to track that down because of the behaviour we got. It is
as I stated in my first message here.

What I did was changing a report (which was designed on an InterBase
database) with the MSSQL Server. After changing some SQL objects I got
messages about columns which couldn't be bound (table_1, etc. see above).
I the manually corrected all table names and removed the unnecessary alias'.
I was able to preview the report on the MSSQL Server now and the report
worked just fine.

But when I used that (changed) report on an InterBase database I got the
funniest results. Some lines where doubled, tripled or even more (the max
was 16x the number of data in the report as it was in the database).

When I then opened the report using the InterBase database and just
accessed all SQL objects in the report (just opening and clicking "ok")
the report worked just fine on the InterBase server (no more duplicated
rows) - but now the report didn't work on the MSSQL server anymore.

This all comes down to the InterBase alias' phenomenon I guess and so we
give a warning before changing a report if the database, the report was
created with differs from the current.

I'm not sure if there's anything you can do about the problem because it
seems to not be a "standard use" of the ReportBuilder.

Kind regards,
Christoph



--- posted by geoForum on http://delphi.newswhat.com

nardmoseley

When you open each query and click Ok, that is the same as iterating over
the dataviews and updating the SQL object. If you do it once for Interbase
and then switch to MSSQL and do it again, does it remove the Interbase
aliasing and get it working again? I don't know if that will help any, give
it a try.




--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com