Closed ktj closed 1 year ago
I can replicate this issue and I also know the solution. :-) The problem is that the length of the value in characters doesn't match the length of the value in bytes. This patch resolves the issue:
--- a/lib/transformer.js
+++ b/lib/transformer.js
@@ -152,13 +152,16 @@ function transformValueIn(info, value, options) {
types.DB_TYPE_NCLOB);
if (info.type !== types.DB_TYPE_CLOB &&
info.type !== types.DB_TYPE_NCLOB &&
- info.cqn === undefined &&
- (info.maxSize === undefined || value.length > info.maxSize)) {
- if (info.checkSize) {
- errors.throwErr(errors.ERR_MAX_SIZE_TOO_SMALL, info.maxSize,
- value.length, options.pos);
+ info.cqn === undefined) {
+ const valueLen = Buffer.byteLength(value);
+ if (info.maxSize === undefined || valueLen > info.maxSize) {
+ if (info.checkSize) {
+ errors.throwErr(errors.ERR_MAX_SIZE_TOO_SMALL, info.maxSize,
+ value.length, options.pos);
+ }
+ info.maxSize = valueLen;
}
- info.maxSize = value.length;
}
return value;
Some more testing is needed but something like this patch will be included in the next release. Thanks for reporting this!
I encountered similar issue with unicode char U+00A0
. It was working with NLS_LANG=".AL32UTF8"
. Since the Thin mode does not follow NLS env vars, I wonder how is it supposed to work? Because JS encodes everything as UTF-16, so it will be the same as AL32UTF8? What if I have a non-unicode server setting?
btw, I have tried the patch above, it does work.
Thin mode uses AL32UTF8 exclusively for communication with the server. If the server is not using AL32UTF8 itself (although that has been the default value for some years now) then the server performs any necessary conversion. What JavaScript uses internally isn't particularly relevant -- the characters in whatever string you supply are encoded to UTF-8 before being sent to the server. The problem was that the code wasn't looking at the length in encoded bytes.
I'm happy to hear that the patch works for you like it does for me!
Thin mode uses AL32UTF8 exclusively for communication with the server. If the server is not using AL32UTF8 itself (although that has been the default value for some years now) then the server performs any necessary conversion. What JavaScript uses internally isn't particularly relevant -- the characters in whatever string you supply are encoded to UTF-8 before being sent to the server. The problem was that the code wasn't looking at the length in encoded bytes.
I'm happy to hear that the patch works for you like it does for me!
thanks a lot!
Hi @anthony-tuininga
I have another question about Thin mode. Previously, I was providing both DB_ORACLE_POOL_SIZE
and UV_THREADPOOL_SIZE
in order to maximize the connections. My understanding is Instant Client would hold a thread until a request finished.
Does it mean, I no longer need to set both DB_ORACLE_POOL_SIZE
and UV_THREADPOOL_SIZE
in Thin mode, and there are just normal (TCP?) requests that will be handled by libuv directly?
[Update] I forked this question to a new issue - let's follow up there.
The patch in lib/transformer.js
for this issue is now available. To apply this patch, simply copy this file to your lib folder and replace the older version.
This will be incorporated in the 6.0.1 release.
Closing this issue as fixed in 6.0.1 release
What versions are you using? oracle version 19c
process.platform darwin process.version v18.16.0 process.arch arm64 require('oracledb').versionString 6.0.0
Is it an error or a hang or a crash? error
What error(s) or behavior you are seeing?
Error: ORA-01460: unimplemented or unreasonable conversion requested
Run with command
NODE_ORACLEDB_USER=SYSTEM NODE_ORACLEDB_PASSWORD=oracle NODE_ORACLEDB_CONNECTIONSTRING=local.oracle.com:1521/xe node test.js
If I change this row
binds = { variable: 'ä' }
tobinds = { variable: 'a' }
, then it works without a problemThis problem didn't exist in version 5.5.0.