Hmmm.  There is an internal column limit that you seem to have exceeded.  The error message indicates that the problem is coming from the Data Server itself. I'm surprised that you didn't see this problem in the Designer.  Does it work correctly in the single-tier Data Manager?

We can take a look at it, but I must admit that this is probably going to be a permanent restriction.  One work around might be, depending on your FD, normalize your table.  That is, to stop making each element of an OCCURS a separate column.  If you turn them into individual rows instead, that will reduce the number of columns and also make your table more SQL like.

Another solution is to split the FD up into two separate tables, and let SQL Server join them back together.

How many columns are we talking about?  The limit seems to be 256.

Thanks for the reply Michael,

I'm afraid I'm pretty ignorant of all thing Cobal.  I'm coming at this from the SQL Server side other than obtaining and configuring the Relativity driver have done little else.  Specifically, I'm unsure of what the Designer or single-tier Data Manager are.  Are these tools that as a user I should have access to?

I am able to contact the developers and will pass on your suggestion regarding normalizing the table.  

Thanks for your help!

Scott

Michael, I neglected to answer your question regarding number of columns.  I'm uncertain as this ODBC driver is the only access I have to the table.  I will find out though.

Michael, I neglected to answer your question regarding number of columns.  I'm uncertain as this ODBC driver is the only access I have to the table.  I will find out though.

Scott,

I agree with Mike Schultz on this.  While I don't remember the exact limit, there is indeed a limit to the number of columns in a table.

And, I will be a bit more direct than Mike on this assessment:  You are almost certainly doing something wrong if you exceed the column limit.  At the very best, you have designed a table that is very difficult for any reasonable end user to comprehend.

Mike's suggestions are good ones.

If you have chosen to expand OCCURS into separate columns, this is almost always a design mistake.  For example, retail accounting software might have OCCURS 13 in many situations.  It is wrong to make these into 13 columns (each).

If you have an OCCURS 13 on a group item, then the data items subordinate to the group item naturally lend themselves to making them into a separate table.  (In the world of relational database, they would be a separate table, without a doubt.)   Note that the default behavior of the Relativity Designer is to normalize the data into 13 rows, repeating .

If you have a situation where the same COBOL record definition has OCCURS 13 (for example) on several data items, and in each of these situations the individual occurrences are associated with retail periods, then you have a situation which is termed 'parallel OCCURS' in Relativity.  The Relativity Designer provides a straightforward mechanism for pulling these parallel OCCURS together so that the correct occurrence of each OCCURS item appears together in a row.  See "Identifying Parallel OCCURS Clauses" in the Relativity Designer help file.

Scott, I just read your latest posts.  Did someone in your organization provide the Relativity implementation, or does it come from an external vendor?

Tom Morrison

Hill Country Software

Interesting.  Well, someone developed the SQL tables and mapped them on top of the COBOL file descriptions. The wording of this message seems to imply that this is being treated as a warning, so perhaps whatever ODBC application is being used by the developers can tolerate the warning and SQL Server does not.  Or perhaps they never actually use this table.  It seems like, if they aren't able to retrieve all of these columns, they should just take some of them out of the table and get rid of the warning.

HI Tom,

The driver was provided by the company who designed and support our system; an external vendor.  They were unfamiliar with the error so I landed on this forum in an attempt to dig deeper.  I had hoped this would turn out to be a configuration issue which could be resolved locally.

From your and Michael's responses I believe I understand this to be a server-side issue which we can't hope to control.  It seems the correct action would be for me to follow this up with our vendor for support unless  you have any other suggestions.

Thanks very much for the quick replies and significant patience!

Scott