-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
amount of characters read by dpiLob_readBytes() #43
Comments
Provided the buffer size you provide is adequate to support the number of characters requested there should be no reason for a short read, but I'll confirm that by asking internally. Note that OCI considers characters to be the same as UCS-2 codepoints. This is true in most cases, but for supplementary characters it is not and the numbers returned are inaccurate. You also have to take care not to split characters. |
Thank you! |
I have confirmed that OCI does not perform short reads, provided that there are sufficient characters available to read in the LOB and the provided buffer is sufficiently large to accept all of the characters requested. So your code you provided above should work just fine! |
Thanks a lot and sorry for bothering you. |
You're welcome. And you're not bothering me at all! You've been a tremendous help asking questions! :-) |
Is it guaranteed that dpiLob_readBytes() reads characters up to the specified amount if it doesn't reach the end of the LOB?
In other words, does the following code work? (Error checks are omitted for simplicity.)
This assume that dpiLob_readBytes() always reads 8192 characters if it doesn't reach the end of the LOB. If this assumption is incorrect, could you change dpiLobReadBytes() or add a new function which returns the number of read characters as OCILobRead2() does? Otherwise, it must be counted in the caller to increment
offset
as follows.The text was updated successfully, but these errors were encountered: