Bug #39729 Error 626 not set on transaction obj with active blob handle and tuple not found
Submitted: 29 Sep 2008 13:04 Modified: 1 Apr 2009 2:22
Reporter: Geert Vanderkelen Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Cluster: NDB API Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: Assigned Account CPU Architecture:Any

[29 Sep 2008 13:04] Geert Vanderkelen 
Description:
Currently, when reading tuples which need a blob handle, and the tuple is not found, the transaction gives success instead of error 626.
A workaround is to check the Operation's error code after doing the NoCommit, which is correctly set to 626, Tuple doesn't not exists..

How to repeat:
  op->readTuple(NdbOperation::LM_Exclusive);
  op->equal("id", id);

  NdbBlob *blob = op->getBlobHandle("fblob");

  // NoCommit is important here
  if( 0 != trans->execute(NdbTransaction::NoCommit) ) {
    APIERROR(trans->getNdbError());
  }

  // Check the operation whether the tuple was found
  // This is workaround.
  if( 626 == op->getNdbError().code ) {
    printf("Tuple not found!\n");
  } else {
    // Read the blob data here
   // data = ..

    if( 0 != trans->execute(NdbTransaction::Commit) ) {
      APIERROR(trans->getNdbError());
    }

    printf("Length: %d; Data: %s\n\n", len, data);
    free(data);
  }
[1 Mar 2009 0:00] Bugs System 
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[1 Apr 2009 23:00] Bugs System 
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".