January 3rd, 2003, 01:54 PM
Crystal Reports Information
I'm still in the process of developing a proposal to implement a good databse system for our intranet at work. One idea that was thrown out awhile ago was that we use Crystal Reports, an idea that I balk at. I'm wondering if anyone here can give me some general info on Crystal Reports. From what I can tell, it seems to be mainly useful in client-side app development and generating reports on data stores. It DOESN'T seem very well-suited to being used for dynamic content delivery on a web-based system (intranet in this case).
Can anyone give me some more info on this app or point me to some good explanations / specs for it? Details seem sort of sparse...
January 3rd, 2003, 03:18 PM
From the little that I've used it, it seemed very much like MS Access's report generator. Fairly easy to use, both for developer and end-user. I don't know about any of its more advanced capabilities, since the only uses I've ever seen it put to have been "report generation", mainly for executive consumtion.
I prefer html since it's more flexible and doesn't require having a special viewer installed.
I just went and looked at the product page for Crystal Reports. The only think I see there that has advantage over plain html is that it's easier for non-technical people to generate their own reports.
Assuming this is related to that whole PGSQL/Access thing, though, if your company is set on CR, it could be a good argument for switching backends. Since CR can pull data from multiple data sources (presumably including PGSQL), and Access has a built-in report generator (why pay for another one?), maybe that could factor into your case.
Last edited by bricker42; January 3rd, 2003 at 03:24 PM.
January 3rd, 2003, 04:02 PM
January 3rd, 2003, 04:14 PM
Eh.. I think I need to clarify - I don't want to use Crystal Reports, I want to kill the idea of using it on a backend system to serve content on a department intranet. As far as I can tell, CR is really one for generating.. well... reports. I know that there is limited support for it with perl modules, but it just doesn't seem to me like it would be a very wise decision to use it as a regular database system.
I want to implement PGSQL, but without native Windoze support, I'll never get it (there's not way they'll put cygwin on the server, I can tell you that right now). I looked over MySql, but the lack of ACID-compliance scares me. The last thing I need is for MySql to process half a transaction and wreck something because stupid WinNT crashed or something.
Really, at the moment though, I'm just trying to determine what the heck CR actually is. Is it a database, is it for generating reports from a database? What?
January 3rd, 2003, 04:40 PM
Well, my company doesn't use it extensively, but we do use it for several applications. I've only seen it used for report generation, and from reading through their documentation, I don't see any mention of it storing data on its own. I do see a lot of phrases like
As far as which database, I know rycamor recommended some alternative open-source databases in a thread awhile ago. One was SAP DB, but you may want to ask him about any others.
January 3rd, 2003, 07:16 PM
I guess misunderstandings abound here. No, Crystal Reports is not a back-end, just a reporting front-end for all sorts of databases and other data sources.
There is no reason to kill the idea of using Crystal Reports, since it does not affect the nature of your actual database or software. Ditto with Datavision, which I suggested above. Report-generating tools such as these are just useful additional tools for helping business owners understand their data. But, they are by no means generalized content-delivery systems, nor are they real programming platforms. They simply provide a convenient drag-n-drop approach to formatting output from queries or groups of queries. Mainly they are used for printable reports.
Really, if you want a combination of database+content delivery system, then you are looking for something like an SQL database of some sort, and a server-side scripting language, such as PHP, Perl, ASP, JSP, ColdFusion, etc...
By the way, there are already people working on a native Windows build of PostgreSQL. See http://archives.postgresql.org/pgsql...1/msg00375.php
and download the beta here: ftp://126.96.36.199/postgres/
Or, if you want another capable SQL DBMS for Windows, you might look at Firebird.
January 3rd, 2003, 07:24 PM
Crystal Reports is reporting. This can be pulled from rdbms, or through some other form of logic, but in the end it is just a reporting tool/generator. I would say that if they want to use CR then an intranet solution is not a real suitable option. CR, or a viewer/activex object would have to be installed on every computer that it would be used at. This defeats one of the main purposes of building an intranet solution, the ability for anyone to view it anywhere in their intranet.
CR is best with GUI apps. This is the most common situation that I have seen it used. We have several applications that uses CR and all of them are VB (and I hate them ALL).
January 3rd, 2003, 08:24 PM
I would like to sincerely apologize to everyone for my poorly phrased question. I really only needed general info on CR because I was having trouble figuring out what it was - but everyone has confirmed what I thought: it's not for development, it's to make pretty reports.
We don't actually need any reporting tools beyond Access, I think my boss was just misunderstanding what CR was. He had actually proposed it as an alternative to Sql Server, to which I kind of said "umm.. yea.. okay.. huh?" but didn't bother arguing it at the time. I'm not going to worry about it then - they want CR, they can have CR and make pretty reports, I'll still need a sound database for the backend.
I had actually considered Firebird, but I haven't had time to evalute it myself, plus I'd either have to eval it on *nix or WinXP Pro (god I hate that OS...), and we're running NT 4.0 at work. I'd definitely like to go with PGSQL, but only if 7.4 really does have native Windows support like they're promising. I can't win with my argument for PGSQL if they (IT) have to "compromise" thier pretty WinNT server by installing cygwin
Like I mentioned before, I really don't trust MySql for this work mostly because of the lack of ACID-compliance.
At any rate, the general issue at hand ("What Is Crystal Report?") is now resolved - thanks a lot to everyone for their responses and bearing with the thread!
January 5th, 2003, 09:04 AM
MySQL is really improving its capabilities over what it was able to do a few years ago. You can get ACID compliance by just using InnoDB tables instead of the native MyISAM tables.
When I was at MySQL's website a couple of days ago, I came across this interesting link: http://www.mysql.com/eweek/index.html
I've used MySQL for several years but hadn't been paying much attention to the improvements that have been made. This ignorance is apparent in the following post. Fortunately another poster cleared that up for me. If you have to use Windows, then MySQL would be a good option. I loaded Firebird on my laptop and it looks pretty good too.
Performance and Scaleability
January 6th, 2003, 12:33 AM
Well, of course you know the database policeman (me) is going to have to step in here .
Oh absolutely, but most of those improvements have been in the area of performance, not logical integrity.
Transactions and foreign key support are only the beginning of a real relational database system. In fact the ACID concept is not the end-all of a database system. That was just intended to be a given, because without it, none of the other logical rules and constraints mean anything.
At present, MySQL is still missing the following:
- CHECK constraints
- stored procedures
- user-defined types and operators
- Multi-version concurrency (the reason PostgreSQL performs so well with mixed inserts/deletes/reads/updates)
Also, another big problem is MySQL's signicant deviation from ANSI-standard SQL. This makes it much more difficult to port your application to Oracle, etc... if your future needs grow.
Also, that old eWeek article you point to above doesn't seem to spend any time dealing with the logical capabilities of the DBMS systems (comparing Oracle to MySQL is apples-to-oranges, if I ever heard it). In fact, as I recall, it was more a benchmark of the JDBC drivers than anything else.
PostgreSQL scores very well on the above list (and more). Maybe PostgreSQL doesn't perform quite as well for certain needs. MySQL is nice and fast if you consider your database as a static repository. But, if your database is dynamic, and needs to have complex business logic, then I would look away from MySQL.
Also, in answer to the above links about MySQL, there are definitely PostgreSQL databases in the >terabyte range, used by some large companies and research projects.
January 6th, 2003, 05:24 AM
Somebody hose rycamor down! Like a Spinal Tap drummer, I think he's about to spontaneously combust...
I wasn't trying to dissuade Ctb from using PostgreSQL. I just wanted to point out that MySQL now had ACID compliance. Also from his post, it looked like he might be stuck using a Windows box. One benefit that I have found from MySQL is the ability to run it on my laptop for prototyping and development. I wish I could do that with PostgreSQL but can't as long as my office uses Windows as its desktop and I'm forced to run it on my laptop as well.
January 6th, 2003, 09:29 AM
Hey. I'm a guitarist, not a drummer, OK. Just don't let me get stuck in one of those metal cocoon thingies .
Yeah, I agree that MySQL has that (small) advantage. That's why I recomended Firebird, which is actually a smaller download than either MySQL or PostgreSQL, but runs on Windows or Unix.
Even though PostgreSQL will have a native Windows version soon, I wouldn't trust my enterprise data on that for at least another year. Much better just to get an inexpensive secondary server and run FreeBSD or Linux.
January 6th, 2003, 09:59 AM
My initial look at Firebird found only one thing that concerned me. On Windows you can use a case-insensitive character set to store the data. The Linux version apparently does not have that option. But I could not find a method to automatically index varchar fields as uppercase.
If a database doesn't allow case-insensitive searching, the way I see it you're left with four options:
I could not find a way to do option 4 on a Linux box with Firebird. This leaves the other three options which all have something disagreeable about them. Maybe I'm missing something and would love to be corrected if I'm wrong. Firebird looks like it has a lot of cool features so I hope I just misunderstood what I was reading.
- Force the users to search for records by typing data exactly like the person who entered it.
- Store all your data in upper / lower case.
- Store one copy of the data as the user entered it and another copy in uppercase. Index the uppercase value and cast all search values to uppercase.
- Store the data as the user entered it, but make your index equal to an uppercase value of the data. When searching always cast the search values to uppercase so the index can find the records.
January 7th, 2003, 01:49 PM
None of these are very practical solutions. Of course it all depends on the nature of the data being stored, but you could validate the data on input to force all upper or lower case as needed. You could also use some string functions to convert the search string to upper or lower case (or both).
The last thing you'd want to do is to make a copy of the data and store it twice.
Will code for food.
January 7th, 2003, 02:14 PM
None of these are very practical solutions.
Correct. But in the absence of a practical solution, I would have to choose the least offensive workable solution. My question was, "Is there a practical solution?".
...force all upper or lower case...
That would option #2 above. I like proper case data. DATA THAT IS IN ALL UPPER CASE DOESN'T LOOK AS GOOD. I ALSO FIND IT HARDER TO READ. IT MAKES (IMHO) UNPROFESSIONAL LOOKING REPORTS.
You could also use some string functions to convert the search string to upper or lower case (or both).
If the database is case-sensitive, then an index will be case-sensitive as well. If the database stores Darryl Caillouet, then the index will store Darryl Caillouet. If you convert the search criteria to DARRYL CAILLOUET, a case-sensitive index won't find it because Darryl Caillouet != DARRYL CAILLOUET. Your indexes are useless if you cast the search fields to a different case.
The best scenario for doing case-insensitive searching in a case-sensitive database is to store Darryl Caillouet, but have the index store DARRYL CAILLOUET automatically. In other words, you define the index to be the uppercase of whatever the user puts into a field. Then you can use a function to convert the search values to upper case, the index will find it and you retain the mixed case of the original data. This is what I could not get to work. It didn't like me using the uppercase function when defining the index. This leaves only two other options: The user has to search for data by typing values exactly as they are entered in the database. Or you have to store both Darryl Caillouet and DARRYL CAILLOUET in the record. One value you display the other you index. Very ugly!