> For reasons too numerous to go into here, I am thinking of moving a
Crystal
> Reports OCX from off of one form, and putting it onto another one. This
OCX
> has been in this particular application since it was originally written,
> some 5 years ago (naturally, getting updated whenever we got a new version
> of Crystal). We now have Crystal Reports 8, but aren't likely to upgrade
to
> 8.5, at least not in the foreseeable future.

> Anyway, when I placed the Crystal Reports control onto the form where I
want
> to migrate it to, I got this little popup telling me that, although
Seagate
> Software continues to support the Crystal Reports 8 OCX, they don't intend
> to add improvements to it. That instead the "preferred" way of using
Crystal
> against databases is to use something called the Report Designer Component
> (RDC) , and then they listed a web site (www.seagatesoftware.com/rdc/),
from
> which if you do a little digging, you can find (as I did) an example VB
app
> which uses the RDC in a VB MDI application. I went ahead and downloaded it
> and played with it a bit. Everything went well, at least for a while. I
> opened up some reports that came along with the demo and closed them,
opened
> up others, etc. Then when I tried to open one of them, VB's IDE crashed. I
> have to believe that it is either a problem with the RDC, or a problem
with
> the way they programmed it. (The programming was fairly simple, they
opened
> up a CRAXDRT.Application object globally, in a .BAS module, so I suppose
it
> is also possible that my opening and closing multiple reports caused a
> memory leak.)

> Anyway, my question is simply this. Does anyone know if there are any
known
> issues with the RDC that ships with Crystal Reports 8, which I need to be
> aware of? If so, I can always go back to the good ol' Crystal Reports OCX.
> Its tried and true, even if features aren't going to be added to it.

> Rod

> There are many issues. I made a couple of lengthy posts a while ago about
> it. Not to be used for serious software development!

> > For reasons too numerous to go into here, I am thinking of moving a
> Crystal
> > Reports OCX from off of one form, and putting it onto another one. This
> OCX
> > has been in this particular application since it was originally written,
> > some 5 years ago (naturally, getting updated whenever we got a new
version
> > of Crystal). We now have Crystal Reports 8, but aren't likely to upgrade
> to
> > 8.5, at least not in the foreseeable future.

> > Anyway, when I placed the Crystal Reports control onto the form where I
> want
> > to migrate it to, I got this little popup telling me that, although
> Seagate
> > Software continues to support the Crystal Reports 8 OCX, they don't
intend
> > to add improvements to it. That instead the "preferred" way of using
> Crystal
> > against databases is to use something called the Report Designer
Component
> > (RDC) , and then they listed a web site (www.seagatesoftware.com/rdc/),
> from
> > which if you do a little digging, you can find (as I did) an example VB
> app
> > which uses the RDC in a VB MDI application. I went ahead and downloaded
it
> > and played with it a bit. Everything went well, at least for a while. I
> > opened up some reports that came along with the demo and closed them,
> opened
> > up others, etc. Then when I tried to open one of them, VB's IDE crashed.
I
> > have to believe that it is either a problem with the RDC, or a problem
> with
> > the way they programmed it. (The programming was fairly simple, they
> opened
> > up a CRAXDRT.Application object globally, in a .BAS module, so I suppose
> it
> > is also possible that my opening and closing multiple reports caused a
> > memory leak.)

> > Anyway, my question is simply this. Does anyone know if there are any
> known
> > issues with the RDC that ships with Crystal Reports 8, which I need to
be
> > aware of? If so, I can always go back to the good ol' Crystal Reports
OCX.
> > Its tried and true, even if features aren't going to be added to it.

> > Rod

> I disagree with Gabriel,

> Depends on how complicated you want you data and application to be.
> I've used the OCX for years, and still use it in some of my applications.
> But I've a couple of new apps that use the RDC happily.

> Works well for me.

> > There are many issues. I made a couple of lengthy posts a while ago
about
> > it. Not to be used for serious software development!

> > > For reasons too numerous to go into here, I am thinking of moving a
> > Crystal
> > > Reports OCX from off of one form, and putting it onto another one.
This
> > OCX
> > > has been in this particular application since it was originally
written,
> > > some 5 years ago (naturally, getting updated whenever we got a new
> version
> > > of Crystal). We now have Crystal Reports 8, but aren't likely to
upgrade
> > to
> > > 8.5, at least not in the foreseeable future.

> > > Anyway, when I placed the Crystal Reports control onto the form where
I
> > want
> > > to migrate it to, I got this little popup telling me that, although
> > Seagate
> > > Software continues to support the Crystal Reports 8 OCX, they don't
> intend
> > > to add improvements to it. That instead the "preferred" way of using
> > Crystal
> > > against databases is to use something called the Report Designer
> Component
> > > (RDC) , and then they listed a web site

> > from
> > > which if you do a little digging, you can find (as I did) an example
VB
> > app
> > > which uses the RDC in a VB MDI application. I went ahead and
downloaded
> it
> > > and played with it a bit. Everything went well, at least for a while.
I
> > > opened up some reports that came along with the demo and closed them,
> > opened
> > > up others, etc. Then when I tried to open one of them, VB's IDE
crashed.
> I
> > > have to believe that it is either a problem with the RDC, or a problem
> > with
> > > the way they programmed it. (The programming was fairly simple, they
> > opened
> > > up a CRAXDRT.Application object globally, in a .BAS module, so I
suppose
> > it
> > > is also possible that my opening and closing multiple reports caused a
> > > memory leak.)

> > > Anyway, my question is simply this. Does anyone know if there are any
> > known
> > > issues with the RDC that ships with Crystal Reports 8, which I need to
> be
> > > aware of? If so, I can always go back to the good ol' Crystal Reports
> OCX.
> > > Its tried and true, even if features aren't going to be added to it.

> > > Rod

> For reasons too numerous to go into here, I am thinking of moving a
Crystal
> Reports OCX from off of one form, and putting it onto another one. This
OCX
> has been in this particular application since it was originally written,
> some 5 years ago (naturally, getting updated whenever we got a new version
> of Crystal). We now have Crystal Reports 8, but aren't likely to upgrade
to
> 8.5, at least not in the foreseeable future.

> Anyway, when I placed the Crystal Reports control onto the form where I
want
> to migrate it to, I got this little popup telling me that, although
Seagate
> Software continues to support the Crystal Reports 8 OCX, they don't intend
> to add improvements to it. That instead the "preferred" way of using
Crystal
> against databases is to use something called the Report Designer Component
> (RDC) , and then they listed a web site (www.seagatesoftware.com/rdc/),
from
> which if you do a little digging, you can find (as I did) an example VB
app
> which uses the RDC in a VB MDI application. I went ahead and downloaded it
> and played with it a bit. Everything went well, at least for a while. I
> opened up some reports that came along with the demo and closed them,
opened
> up others, etc. Then when I tried to open one of them, VB's IDE crashed. I
> have to believe that it is either a problem with the RDC, or a problem
with
> the way they programmed it. (The programming was fairly simple, they
opened
> up a CRAXDRT.Application object globally, in a .BAS module, so I suppose
it
> is also possible that my opening and closing multiple reports caused a
> memory leak.)

> Anyway, my question is simply this. Does anyone know if there are any
known
> issues with the RDC that ships with Crystal Reports 8, which I need to be
> aware of? If so, I can always go back to the good ol' Crystal Reports OCX.
> Its tried and true, even if features aren't going to be added to it.

> Rod

> Here's what I had to say to someone else about Crystal and the RDC:

> Here's just a list of problems we've experienced:

> - The DAO database driver: unacceptable performance - 1 minute to display
an
> invoice on a P3/800. Since this driver cannot accept a SQL Query or send
one
>  to the Jet engine, it scanned the whole table to locate the appropriate
> record. Imagine when you have inner joins with that

>  - DAO driver again: it references index fields (why does it have to do so
> anyway) by it's GUID. The GUID seems to change considerably over time,
>  rendering the report unfunctional and requiring a "Verify Database"
> operation. Imagine the hassle when distributing an application to
>  thousand's of customers like we do.

>  - Now on to another driver: pdsoledb, for ADO/OLE DB. This one does not
> work with secured Access database (known bug - never got fixed).

>  - Another problem with the OLE DB driver: you can't pass it a connection
> string or change the data source at run-time. The driver will only
> accept a live recordset, which in my opinion is way to much work

>  - Another database driver: ODBC. Now this one works almost correctly.
> Except for some times where it recognizes number fields as strings or
> currency
>  fields not recognized properly. This is the one that we used to ship our
> application [UPDATE: You can't have an ODBC connection that points to a
MDB
> database that contains any special character like .,; - strange errors
> getting returned if so].

>  Is that enough yet for you? And it's just the beginning...

> - We need to manipulate the report at run-time to change it's fonts,
colors
> and other properties. This is a feature offered by our print setup
> screen, and we save the settings to a database. In version 8.0, if we
change
> the color of a field, things start working incorrectly with it. We were
then
> sent a beta DLL that was supposed to fix this, but it caused so many other
> problems! And believe it or not, the problems are still present in the
final
> version of 8.5.

> - Regarding manipulating the report at run-time: If you try to export a
> report that was manipulated using the event model (the _Format events),
all
> that you've done in this step is not exported. We're translating our
reports
> at run-time. I haven't seen this documented anywhere on Seagate Software
> site.

>  - Regarding exporting: most of these export DLLs don't work properly.
> Strange layout, missing numbers, etc. The only one that is acceptable is
the
> PDF export, but it has only recently been available in a final, stable
> version (even if it is listed on the box and in documentation).

> - Exporting again: The export button of the RDC viewer does not work on
> Windows 2000, it creates a 0-byte file. Known problem, never fixed.

>  - Parameter fields: If you can find a "correct" way to pass parameter
> fields, tell me. I still haven't figured out which method between the 5-6
> (!) that are available is the best.

>  - Drill-down: This is a nice feature of Crystal Reports. When a user
> double-clicks on a field, we open the corresponding VB screen. Worked
> fine in version 7.0 and 8.0. It got broke in the beta DLL that we got for
a
> problem that I listed above. In the 8.5 final release, it's still broke.
> It's been assigned a "track id", but i doubt it will get fixed in less
that
> 3-4 months [UPDATE: Still no patch available]. They don't care about their
> developers, they only care about SAP and JD Edwards users who spend
milions
> on a shitty product.

> - Deployment issues: so many DLLs to ship, ~10mb in our case. We had
> problems getting the MAPI export destination to work on our clients, and
> finally were told by Seagate that we needed to modify the system.ini file
> (this thing still around after all these years?)

> - Horrible support: Try it for yourself - you'll get a fast answer, but
not
> necessarily the one you want.

> - Finally, the infamous RDC crash: In the first version of Crystal
8.0(that
> is, the version that was available from february last year to late
summer),
> Visual Basic would crash if you had more than 3-4 reports in a project and
> user controls would vanish. I mean, who is designing real world
applications
> with 4 reports? We have _150_, and this is a small number compared to what
> we're working on now. When this problem finally got fixed, we were able to
> move to Crystal 8.0, but projects are very slow to start on the first run
> (more than 2 minutes on a fast pc).

> Bottom line, if you have to use Crystal Reports, keep your files in a
.rpt,
> don't manipulate the report at run-time, use the ODBC driver AND be
prepared
> for serious headaches. It might be a good product, but it is not made for
VB
> developers at all. We are slowly abadonning it, and the day i'll be able
to
> uninstall it from my system i'll say good riddance [UPDATE: We are
> abandonning it ASAP].

> > I disagree with Gabriel,

> > Depends on how complicated you want you data and application to be.
> > I've used the OCX for years, and still use it in some of my
applications.
> > But I've a couple of new apps that use the RDC happily.

> > Works well for me.

> > > There are many issues. I made a couple of lengthy posts a while ago
> about
> > > it. Not to be used for serious software development!

> > > > For reasons too numerous to go into here, I am thinking of moving a
> > > Crystal
> > > > Reports OCX from off of one form, and putting it onto another one.
> This
> > > OCX
> > > > has been in this particular application since it was originally
> written,
> > > > some 5 years ago (naturally, getting updated whenever we got a new
> > version
> > > > of Crystal). We now have Crystal Reports 8, but aren't likely to
> upgrade
> > > to
> > > > 8.5, at least not in the foreseeable future.

> > > > Anyway, when I placed the Crystal Reports control onto the form
where
> I
> > > want
> > > > to migrate it to, I got this little popup telling me that, although
> > > Seagate
> > > > Software continues to support the Crystal Reports 8 OCX, they don't
> > intend
> > > > to add improvements to it. That instead the "preferred" way of using
> > > Crystal
> > > > against databases is to use something called the Report Designer
> > Component
> > > > (RDC) , and then they listed a web site
> (www.seagatesoftware.com/rdc/),
> > > from
> > > > which if you do a little digging, you can find (as I did) an example
> VB
> > > app
> > > > which uses the RDC in a VB MDI application. I went ahead and
> downloaded
> > it
> > > > and played with it a bit. Everything went well, at least for a
while.
> I
> > > > opened up some reports that came along with the demo and closed
them,
> > > opened
> > > > up others, etc. Then when I tried to open one of them, VB's IDE
> crashed.
> > I
> > > > have to believe that it is either a problem with the RDC, or a
problem
> > > with
> > > > the way they programmed it. (The programming was fairly simple, they
> > > opened
> > > > up a CRAXDRT.Application object globally, in a .BAS module, so I
> suppose
> > > it
> > > > is also possible that my opening and closing multiple reports caused
a
> > > > memory leak.)

> > > > Anyway, my question is simply this. Does anyone know if there are
any
> > > known
> > > > issues with the RDC that ships with Crystal Reports 8, which I need
to
> > be
> > > > aware of? If so, I can always go back to the good ol' Crystal
Reports
> > OCX.
> > > > Its tried and true, even if features aren't going to be added to it.

> > > > Rod