Cosmark, from your description I think Relativity will do the job you want. You will need the file descriptions and COBOL (not SQL!) SELECT statements used in the application; it is unclear from your description whether your client has access to these.
Richard has raised some issues to which I can add some technical information.
1. I assume here that Richard is discussing data items containing, or subordinate to, OCCURS clause. As an example assume a very simple example:
Code:
01 record-name.
02 key-item pic x(10).
02 fixed-part-of-record.
03 first-name pic x(20).
03 last-name pic x(20).
02 monthly-payment-history occurs 12.
03 beginning-balance pic s9(12)v9(4).
03 payments-applied pic s9(12)v9(4).
03 ending-balance pic s9(12)v9(4).
I think Richard is implying that he would define 36 columns to cover the data within monthly-payment-history (informally called spreading a table). However, this does not produce a very good relational data model. It would be better to produce 12 rows, with three columns. In fact, Relativity's preferred mode of operation would be to produce 12 rows (informally called unrolling a table) with a column for beginning-balance, payments-applied, ending-balance, AND another column based upon the occurance number implied by the definition -- four columns in all.
This is not a thorough example. Relativity will allow either model (unrolled or spread), and has tools in the Designer to easily accomplish either.
2. Relativity handles NULL (in the SQL sense) quite well. Perhaps Richard is writing of the inability of MS Access to deal with ASCII NUL characters (binary zero) in fields that it expects to contain character data. I speculate that this is due to the fact that the C programming language treats a binary zero character as the termination of a character string. This flaw of MS Access is not seen in other packages; however, it is probably true that one should not expect ODBC-enabled reporting tools to understand character fields containing LOW-VALUES...
3. Relativity is a forward-only driver. Relativity is not slow in general.
4. ODBC specifies an SQL grammar and divides it into segments: minimum, core and extended. Relativity implements all of minimum (an absolute requirement of any ODBC driver), and most of core and extended. I am not aware of which SQL standard Richard is using as "the" full SQL language; most of the "industrial strength" database products have several extensions that are not specified in the ODBC standard, which is a subset of the ISO SQL-92 standard.
5. Joins are constrained by the keys available in the files. Poorly constructed joins can cause
any database to slow to a crawl.
6. This is true. Multiple record types are a fact of life in most COBOL applications. The relational model does not have an analog (multiple row types?!). The most straightforward way of dealing with this reality without imposing some really stupid data model on the SQL user is to define a table for each record type.
7. I consider two different types of redefinition: macro and micro. See 6 above (multiple record types) for large scale, multiple record type redefinition. I consider the micro redefinition to be where one field in a record is used for two purposes depending on a flag somewhere else in the record. For example, suppose a pic 9(5)v9(4) field is used as either a percentage discount or an absolute amount discount, depending on another field's value (the flag field). In my opinion, it is best to set this up as two columns in the table (i.e. PercentDiscount and AmountDiscount), and use the flag field's value to cause an SQL NULL to be returned in one or both of the columns. The SQL data model here is not distorted.
8. Client-Server works quite well. I think that Richard's 9th comment probably ties to this issue, since he clearly had two years of frustration, without any success to show for it. Client-Server is appropriate to reduce network traffic: send a query to the server and receive back a set of rows. Client-Server does imply a bit more administrative work. I would ask Richard to email rm_support@liant.com, with a specific request to forward to me, including such information as server platform, Relativity version number, problem, etc., as well as a brief description of his communications over the two years, so that I can correct this matter if at all possible.
9. Liant support is an email away (see above or our web site). I do not minimize the difficulties that Richard has apparently had getting appropriate support, but I will claim that it is not typical (I get involved with most of the 'tough ones' on the Relativity product, and I am not familiar with his problem). Liant also has a CEO who takes customer feedback quite seriously.
Tom Morrison
Liant Software Corporation
