[ 
https://issues.apache.org/jira/browse/DERBY-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Pendleton reassigned DERBY-6901:
--------------------------------------

    Assignee: Edirisinghe Lokuge Yeshan Tharaka

> 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.1.0
>            Reporter: Danoja Dias
>            Assignee: Edirisinghe Lokuge Yeshan Tharaka
>            Priority: Minor
>         Attachments: petlist.csv, repro.java
>
>
> 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.4.14#64029)

Reply via email to