> Before committing myself to new troubles - have you had any
> problems with RB

<...>

Downside...

Various features dont work seem to work as reliably as they should.
You seem to have to learn (the hard way) when things like cross-tab
will work properly. Setting MasterPipeline can actually cause reports
to act in strange ways.

Its pretty slow and the caching mechansim does not operate very well
so that even scrolling back though pages already processed is very
slow.

It always requires bufferred datasets which adds to its memory useage.

Probably the most upsetting was the change from RB5.1 to RB5.5 when
major changes occured cause various things to break. Hopefully they
have got this out of their system and will do better in the future :-)

As a BCB user you may not get the best from their support department,
since they dont officially support BCB.


Upside...

Printing to different printers seems good and reliable (same mistakes
happen regardless of the printer ;-)

End-user report editor is excellent.

There has not been much I have not been able to do. I found that the
best way to get RB to work predictably is to write stored procedures
that collate all the information required into a single result set and
then use the grouping features of RB to format the report (rather than
trying to use master-detail relationships in datasets on the
form/report). Now that I have learnt this lessen I seem to be getting
reasonable results - although I still intend to find something else
eventually.

Overall component design seems to be very good. I have been able to
integrate RB into my applications with minimal problems - when I had
significant problems with other packages that I tried (trying to make
them operate within my application as I wanted).

> BTW, is the RB built like QR - all labels and fields are separate
> components? I'm using Multilizer tool for translating my app into
> different languages and it does this automatically.

Yes. You can save reports to .rtm files as text (or binary). These
seem to use the same format as dfm files, making it possible to edit
the report files directly if required.

> The FastReport for example keeps his Labels in his own format
> so it's very inconvenient to translate them.

I did read that. Its interesting to understand the possible
implications of this decision.


Geoff Worboys
Telesis Computing