fix: Prevent Statement is dropped Error

[czindel-sap]

I can not clearly tell how to reproduce the Statement is dropped error, but I receive it sometimes. Maybe it depends on execution times.
For my understanding after the result is read, the result set should be closed and the result should be returned (https://github.com/cap-js/cds-dbs/blob/main/hana/lib/drivers/hana-client.js#L115). After the result is returned the prepared statement will be dropped. But as there is an additional executeQuery call after the close, it might happen that the statement is already dropped. I am not to deep in the details of the implementation, but I wonder if there is a scenario where this second executeQuery is needed.

[BobdenOs]

@czindel-sap this change seems to be counter acting the error message.

Please make sure to use the statement inside the transaction, because on commit / rollback all statements are dropped. So what this seems like with the limited information is that the logic is trying to read a blob stream after the transaction is committed.

So make sure that the following is going on:

cds.tx(async () => {
  const res = await SELECT('ID,blob').from(entity)
  for(const row of res) {
    // Make sure to do all reading of blobs in the transaction
    const blob = await buffer(row.blob)
  }
})

[czindel-sap]

@BobdenOs I tried to remove all the "noise" from our project and boiled it done to

service AppService {
    entity ENTITY_WITH_BINARY {
        key ID    : Integer;
            VALUE : cds.Binary;
    }
}

and a simple http://localhost:4004/odata/v4/app/ENTITY_WITH_BINARY request. I can still see in https://github.com/cap-js/cds-dbs/blob/main/hana/lib/drivers/base.js#L170 that the error occurred. I am not sure about the error handling, but it does not show up in the console.

[BobdenOs]

Here is a stack trace to explain what is happening.

1. GET('/odata/v4/app/ENTITY_WITH_BINARY')
2. reading starts all
3. reading finishes and calls reset
4. reset will close the result set
5. once close detaches from the main thread commit is called. Which closes all open statements.
6. when close is finished the reset function tries to open a new result set. Which fails as commit has already dropped the statement.
7. The error Statement is dropped is thrown by the client and this error is passed along to any future stream consumers. If no streams are created the error is ignored.

Which works as intended even if the error message Statement is dropped is not very nice, but it shouldn't be thrown unless a stream is trying to escape its source transaction.