Crystal reports

Stormaye · Post by **Stormaye** » Mon Jan 08, 2007 1:10 pm

Any of you tech folks used Crystal Reports before? I'm switching from a home-brewed reporting system to something a little less time consuming, and wondering if this is worth the learning curve.

TIA

Rsak · Post by **Rsak** » Mon Jan 08, 2007 7:45 pm

From an industry perspective its a very marketable skill to learn.

Certainly the database design and application can be used in numerous fields.

Post by **Ddrak** » Mon Jan 08, 2007 7:56 pm

Definitely worth the time to at least look at. I'd say the same for MS Reporting Services as well. If you're coming from a home-grown system it could either seem like heaven or hell, depending on how good a fit it is to what you are trying to accomplish.

As Rsak pointed out, it's a great skill for a resume too.

Dd

Freecare Spiritwise · Post by **Freecare Spiritwise** » Wed Jan 10, 2007 1:17 pm

/Shrug it's a good product I guess, though I haven't used it in anything production since 1996. It's easy enough to pick up that if it was thrust upon me (hey, it's .NET now after all) I wouldn't have a problem with it. We pretty much do whatever the clients ask for.

But my theory is that all reports end up as home brewed eventually due to "feature creep". I have a bunch of slick PDF toolkits that I use for printable documents, and a basic home brew online report is now 100 lines of .NET code. I also use 3rd party widget toolkits, so I can build a much more interactive online report than anything Crystal Reports can give me.

Frank O Pinion · Post by **Frank O Pinion** » Thu Jan 11, 2007 8:22 am

I've used Crystal since the mid 90s and was one of their Tech Advisors (basically meant we got to beta test releases in exchange for free licenses) for a few years.

It's a very good product - not great, but very good. It can be incredibly frustrating at times, but I've not found an easier reporting tool to learn or deploy. You can create slick looking reports with very little effort or time. They have never quite figured out how to make complex database joins work well, but there are standards that most CR developers have simply come to accept as necessary when working with CR (e.g. rather than cluge along with CR's table linking simply use sql to populate a 'report' table with the data set you want in your report and once the data is there kick off the report configured to look at that table, once the report is complete you can trunc the table).

My company recently shifted from home-rolled reporting to CR due mainly to the time savings. Out of the box it offers a lot fo features that are easily learned and deployed. Its certainly not the ends-all-beats-all, but in terms of cost\features\learning curve its a good choice.

-FrankO

Post by **Ddrak** » Thu Jan 11, 2007 10:15 am

They have never quite figured out how to make complex database joins work well, but there are standards that most CR developers have simply come to accept as necessary when working with CR (e.g. rather than cluge along with CR's table linking simply use sql to populate a 'report' table with the data set you want in your report and once the data is there kick off the report configured to look at that table, once the report is complete you can trunc the table).

Heh - we used to populate an ADO Recordset and pass that to the Crystal engine rather than letting Crystal go near the database for pretty much the exact reason you just stated. Just didn't want to mess with report tables in a multiuser environment.

We recently switched to MS Reporting Services, but I'm not sure it was a good move just yet. MSRS is pretty new, and has some interesting "features".

Dd

Freecare Spiritwise · Post by **Freecare Spiritwise** » Thu Jan 11, 2007 2:14 pm

Sometimes the real world is ugly, and the reports have to reflect that.

Any random report from one of my systems could mashup data from SQL Server, 20 year old cobol legacy apps, Web Services, flat files, etc.

If all your data is stored in a plain SQL database, I'm sure you could bend CR to your will just fine.

I will probably take a look at the MS reporting services. For development at least, MS has always been good about giving the people what they want.

Heh - we used to populate an ADO Recordset and pass that to the Crystal engine rather than letting Crystal go near the database for pretty much the exact reason you just stated. Just didn't want to mess with report tables in a multiuser environment.

Recordset, or dataset? If it took generic datasets, you could probably hand craft them to get CR to take any data. I guess you could also make any data look like a recordset if you tried hard enough...

Post by **Ddrak** » Thu Jan 11, 2007 2:22 pm

We were using ADO (v1.5 actually if you really want to date the app), not ADO.NET so there wasn't any concept of a DataSet.

I'm pretty sure the Crystal Reports stuff for .NET will take a DataSet though. Haven't looked for a year or so.

MSRS *requires* SQL 2005 of some form (the embedded MSDE is fine) as a front-end database server - just be prepared if you're going to go that route.

Dd

Freecare Spiritwise · Post by **Freecare Spiritwise** » Thu Jan 11, 2007 3:49 pm

Datasets are so cool that I don't think I've even used a recordset in .NET - ever. Not even indirectly with a data-bound control.

No more:

If data is SQL then
DoSomethingWithSQL()
elseif data is xml then
DoSomethingWIthXml()
else
end if

Now its:

GetData()
DoSomethingWithData()

As long as the app is using its data uniformly, then it shouldn't care where the data came from, which is why I have teh lovins for .NET

Finglefinn · Post by **Finglefinn** » Thu Jan 11, 2007 5:03 pm

hihihi!1 WTF are you guys talking about? hihi!@ \o/

Freecare Spiritwise · Post by **Freecare Spiritwise** » Thu Jan 11, 2007 7:07 pm

Finglefinn wrote:hihihi!1 WTF are you guys talking about? hihi!@ \o/

Mostly about duct-taping together enough hamsters to get more booze and hookers. It's all very technical, so shhh.

Stormaye · Post by **Stormaye** » Fri Jan 12, 2007 10:26 am

Thanks folks, got my dev version of CR today. Time to start learning the API a little more closely.