jhc@m2jhc.uucp (James H. Coombs) (07/25/90)
In article <1990Jul25.070404.4330@wam.umd.edu> gravity@wam.umd.edu (Rick Kissh) writes: >I am considering purchasing a product named CQL from Machine Independent >Software Corp. located in Reston, VA. CQL is an implementation of ANSI 1986 >SQL with extentions [sic]. I have it sitting on my shelf. I evaluated it for use under Unix. It has been about a year since I looked at it for use with c-tree. We use c-tree for all of our databases. I can't say now exactly what is wrong with it. It is tantalizing but just does not do the job that we needed it for. It did take me a couple of days to come up with an executable that could actually create a database, and I found that very frustrating. Unless they have a version designed for Unix, you can expect to expend some effort getting it running. Now it is coming back to me. I *suspect* that CQL does not support compound keys (constructed from more than one field). Subjectively, I have never felt that I was working with a professional package. The documentation is sparse. The comments in the source code are even sparser. We then took a look at db_Files and db_Retrieve (complete with some vehement discussion in this group). They do not support varying length records, as I recall. We could have tried db_Vista, but people felt that it was too expensive, and I *think* there was no query optimization in the SQL engine. Also, people were very happy with c-tree, which gave us simplicity, reliability, and performance that we had never enjoyed with Ingres. They were reluctant to make another change, especially toward something that looked bigger and more complicated. In the end, we agreed that it would be more cost effective to develop our own query engine, which could support a subset of SQL and be optimized and tuned to our needs. Without a doubt, it was more cost effective: we scrapped the project for other reasons. Hope these vague recollections help. --Jim