[
https://issues.apache.org/jira/browse/DERBY-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danoja Dias updated DERBY-6901:
-------------------------------
External issue URL: (was:
https://issues.apache.org/jira/browse/DERBY-4555#)
> SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line
> numbers in the same error message.
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6901
> URL: https://issues.apache.org/jira/browse/DERBY-6901
> Project: Derby
> Issue Type: Bug
> Components: Miscellaneous
> Affects Versions: 10.13.0.0
> Reporter: Danoja Dias
> Priority: Minor
>
> SYSCS_IMPORT_TABLE_BULK and SYSCS_IMPORT_DATA_BULK procedures gives two
> different line numbers in same error message.
> For a test like following
> cSt = prepareCall(
> " call SYSCS_UTIL.SYSCS_IMPORT_DATA_BULK(null, "
> + "'PET' , null , '1,2,3' , 'extinout/pet.dat' "
> + " , null , null , null, 0, 7) ");
> it gives the error message
> [junit] Import error on line 1 of file extinout/pet.dat: Read end of file at
> unexpected place on line 7.
> Note : pet.dat file has only 6 lines to be imported.
> There are multiple objects of importReadData. One is used by readHeaders()
> method in Import.java which is maintaining its own lineNumber.
> The problem involves the fact that the Import object and the ImportReadData
> object are two separate objects, and the Import object has a "lineNumber"
> (which is actually in the ImportAbstract superclass), and the ImportReadData
> object has a separate "lineNumber".
> It's possible that if ImportAbstract.getCurrentLineNumber()
> were changed so that it checked to see if its importReadData
> member was non-NULL, and then returned
> importReadData.getCurrentRowNumber() rather than simply always
> returning its own lineNumber, then these error messages would
> report the lineNumber better in more cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
