Re: DERBY-6901

[Rick Hillegas]

On 9/18/17 9:17 AM, Yeshan Tharaka wrote:

hi,
I was able to find the SYSCS_IMPORT_DATA_BULK implementation. But 
Import.importTable() cannot be found? So can you please give me some 
details about it.? Thank you very much..


On Mon, Sep 18, 2017 at 9:38 PM, Yeshan Tharaka 
<elyeshanthar...@gmail.com <mailto:elyeshanthar...@gmail.com>> wrote:


hi,
    Regarding DERBY-6901 issue.

Can you please help me to find out the location of
SYSCS_IMPORT_DATA_BULK implementation?
Thank you.



There is one class named Import.java in the source tree:

  java/engine/org/apache/derby/impl/load/Import.java

Hope this helps,

-Rick

Re: DERBY-6901

[Yeshan Tharaka]

hi,
I was able to find the SYSCS_IMPORT_DATA_BULK implementation. But
Import.importTable()
cannot be found? So can you please give me some details about it.? Thank
you very much..

On Mon, Sep 18, 2017 at 9:38 PM, Yeshan Tharaka <elyeshanthar...@gmail.com>
wrote:

> hi,
> Regarding DERBY-6901 issue.
>
> Can you please help me to find out the location of SYSCS_IMPORT_DATA_BULK
> implementation?
> Thank you.
>

DERBY-6901

[Yeshan Tharaka]

hi,
Regarding DERBY-6901 issue.

Can you please help me to find out the location of SYSCS_IMPORT_DATA_BULK
implementation?
Thank you.

Re: About DERBY-6901 issue.

[Bryan Pendleton]

I'm not 100% sure which implementation of the method is important to your
research, but start looking here:

http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/am/ClientConnection.java

and here:

http://svn.apache.org/repos/asf/db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java

thanks,

bryan


On Mon, Jul 24, 2017 at 9:21 PM, Yeshan Tharaka 
wrote:

> Hello,
> Where can I find the prepareCall() method in source code?
> Thank you.
>

About DERBY-6901 issue.

[Yeshan Tharaka]

Hello,
Where can I find the prepareCall() method in source code?
Thank you.

Re: DERBY-6901

[Bryan Pendleton]

Welcome to Derby!

I have marked you as the assigned contributor for DERBY-6901.

Please update the issue in JIRA with the results of your investigations and
study, and you can attach your proposed contribution to the issue as you
proceed.

thanks,

bryan

[jira] [Assigned] (DERBY-6901) SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line numbers in the same error message.

[Bryan Pendleton (JIRA)]

 [ 
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)

DERBY-6901

[Yeshan Tharaka]

Hello,
I would like to contribute https://issues.apache.org/jira/browse/DERBY-6901
issue.
My jira user id is yeshantharaka.
Thank you.

[jira] [Updated] (DERBY-6901) SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line numbers in the same error message.

[Danoja Dias (JIRA)]

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

Danoja Dias updated DERBY-6901:
---
Attachment: repro.java
petlist.csv

> 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
> 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.3.4#6332)

[jira] [Updated] (DERBY-6901) SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line numbers in the same error message.

[Danoja Dias (JIRA)]

 [ 
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)

[jira] [Created] (DERBY-6901) SYSCS_IMPORT_TABLE_BULK , SYSCS_IMPORT_DATA_BULK gives two different line numbers in the same error message.

[Danoja Dias (JIRA)]

Danoja Dias created DERBY-6901:
--

 Summary: 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)