VB6 & Crystal Reports 8: the Crystal Reports OCX vs. the Report Designer Component 
Author Message
 VB6 & Crystal Reports 8: the Crystal Reports OCX vs. the Report Designer Component

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



Mon, 08 Dec 2003 02:02:43 GMT  
 VB6 & Crystal Reports 8: the Crystal Reports OCX vs. the Report Designer Component
There are many issues. I made a couple of lengthy posts a while ago about
it. Not to be used for serious software development!


Quote:
> 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



Mon, 08 Dec 2003 02:40:33 GMT  
 VB6 & Crystal Reports 8: the Crystal Reports OCX vs. the Report Designer Component
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.


Quote:
> 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



Mon, 08 Dec 2003 06:46:13 GMT  
 VB6 & Crystal Reports 8: the Crystal Reports OCX vs. the Report Designer Component
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].


Quote:
> 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/),

- Show quoted text -

Quote:
> > 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



Mon, 08 Dec 2003 09:36:57 GMT  
 VB6 & Crystal Reports 8: the Crystal Reports OCX vs. the Report Designer Component
Personally I have found the version 8.5 with the new drivers excellent and
the flexibility it gives you from inside your application is brilliant.

You can generate reports with multiple softcoded database connections using
various drivers without complaint.  One big advantage is the ability to
reference everything within the report as an object in your application.

However I still create the reports outside of the application and then dim
the report from inside my app.  main reasons for this are the space the RDC
takes within the app and it also appears that your apps crash more
frequently when using the designer inside.

Malcolm

Quote:
> 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



Mon, 08 Dec 2003 22:24:17 GMT  
 VB6 & Crystal Reports 8: the Crystal Reports OCX vs. the Report Designer Component
Gabriel,

Thanks for your comments.  It looks like your data access and volumes are
larger and more complex than mine.  I'll keep those in mind if it becomes an
issue for my applications.

I use DAO and ODBC, MS access, SQL server, vb5 and 6.  But I don't push my
reports into the areas you've been finding problems.  And I've kept all my
rpt files out of my VB code, so the 4 report limit has never been seen.

Best wishes in your conversion. let us know how it goes.  I just hope you
are not exchanging one set of problems for a yet undiscovered set of new
problems.

Regards

Bruce


Quote:
> 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



Tue, 09 Dec 2003 07:37:44 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Crystal Report vs MS Data Report Designer

2. Help: VB6 Crashes after adding Crystal Report 6.0 Designer report

3. Crystal Report 7 ActiveX (craxdrt.dll) vs Crystal Report Engine (CPEAUTO.dll)

4. Crystal Reports 8.5 (VB6) to Crystal Reports NET (VB.NET) conversion

5. Printing Crystal Reports without Crystal Control ActiveX or Crystal Reports API call

6. How to use Embeddable Crystal Reports 9 Designer Control to edit RDC Report

7. Crystal Reports 6 Report Designer Component

8. Crystal Reports Report Designer Component

9. Crystal Report Designer Component (Previewing a report.)

10. Is there any report designer better than crystal report

11. Adding several reports to vb app with crystal report 6.0 designer

12. Crystal Reports "Report Designer Component"

 

 
Powered by phpBB® Forum Software