[ https://issues.jboss.org/browse/TEIIDDES-1315?page=com.atlassian.jira.plu... ] Paul Nittel updated TEIIDDES-1315: ---------------------------------- Attachment: Cars_FixedLength.txt ColumnLengthsNotQuiteRight.png AddingSecondColumn.png Attaching the fixed-length data file, a pic of the incorrect column lengths, and defining the second column. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIIDDES-1315?page=com.atlassian.jira.plu... ] Barry LaFond commented on TEIIDDES-1315: ---------------------------------------- Paul's comments: Narrowed down the problem to the TransformationSQLHelper, which as I understand it extracts the SQL values from the SQL string and applies them to the model that back the gef editor. Trouble is the method getProjectedSymbolLengths() is responsible for applying the lengths and although it has the SQL query makes no attempt to extract the WIDTH values and instead resorts to default preferences. Question in a rather roundabout way is, should the WIDTH values in the SQL be parsed and applied to the model?\ Think we can be a little more proactive here. I think in the FlatFileViewModelFactory.createViewTable() method we can use the columns in the TeiidMetadataInfo object to construct the actual EMF columns of the new table and set the length directly. Setting the SQL will not create the columns if they already exist. See ImportWsdlProcessor.createViewWrapperProcedure() for an example. It's a procedure, but the BaseTable object would be similar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira