You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <ji...@apache.org> on 2007/05/14 22:23:16 UTC

[jira] Updated: (DERBY-2639) Bulk data load utility should indicate when it is finished.

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

Daniel John Debrunner updated DERBY-2639:
-----------------------------------------

    Component/s: Store

> Bulk data load utility should indicate when it is finished.
> -----------------------------------------------------------
>
>                 Key: DERBY-2639
>                 URL: https://issues.apache.org/jira/browse/DERBY-2639
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.2.0
>         Environment: Java Version:    1.5.0_06
> Java Vendor:     Sun Microsystems Inc.
> OS name:         Windows XP
> IDE:  Eclipse
> Derby:  10.2.2,  running Embedded
>            Reporter: Patty Parker
>
> The bulk load CALL SYSCS_UTIL.SYSCS_IMPORT_DATA  appears to be finished (i.e. the statement returns), but it is not entirely 
> finishing before I try to query the table it is populating.  I would expect to get a locking exception, or something of that nature, but 
> the error I get is either SQLERROR XSCB1  or SQLERROR XSCBH1, Container <containerName> not found.  It has given me both at different times.  
> An improvement I would suggest is having SYSCS_UTIL.SYSCS_IMPORT_DATA indicate when it is done loading.  As it stands now, the thread I have running it finishes before the utility finishes, and I have no elegant way of knowing when the load is done, other than trying to use the table and trapping for I listed above.
> For more information, please see the post "SQL Exception: Container xxx not found" in derby-user mail list.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.