Whether for lan use or web use?

Thanks for any thoughts,

Al Frick

Good Luck\

Al

David

http://www.*-*-*.com/

Thanks
David

There's a trial version available on the web - only restriction is that it
places a little banner in the footer.

Thanks for info
David

Here is a message I posted a while ago in the newsgroups regarding Crystal.

I couldn't agree more that most people *think* Crystal is a good product.
I've been working at Dynacom for one year and I am now lead developer, and
it has taken all this time to convince my boss to at least try another
report designer. He is so convinced by Active Reports that he even asked me
if it was possible to redo all the reports in our current version.

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].

We are developing accounting software that's sold retail across Canada (take

a look at www.mydynacom.com). We don't do any web, but it also works over

the web and they have ActiveX and Java viewers - check out their site they

have a nice preview in the "showcase" section.

Here is a message I posted a while ago in the newsgroups regarding Crystal.

I couldn't agree more that most people *think* Crystal is a good product.

I've been working at Dynacom for one year and I am now lead developer, and

it has taken all this time to convince my boss to at least try another

report designer. He is so convinced by Active Reports that he even asked me

if it was possible to redo all the reports in our current version.

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].

Check out R&R Report writer.  Much the same as Crystal.  A lot cheaper.
Free runtime license.

www.rrreportwriter.com

Howard Hammerman
Hammerman Associates, Inc.
Crystal classes, consulting, books, support
www.hammerman.com
800-783-2269