Zeoslib Portal

My huge issue in the UTF16 error (and the AL32UTF8 64-bit AV too) is my current debugging and this deep Zeos knowledge doesn't seem to be sufficient. I did play around in both and however I did achieve an effect - I did not find the root cause and therefore could not fix them myself. I'm looking at...

I actually don't mind tnsnames.ora. I think I need to use it currently since I use the Oracle Wallet thing. However I find that a lot of issues occur if you don't use TNS_ADMIN to force its location. You can do that with an environment var set before the client load or you can set it in the registry...

That's been possible since way back. Alternately you can use the EZConnect syntax: //server/sid (it can be more complex than that.) https://docs.oracle.com/en/database/oracle/oracle-database/18/ntcli/specifying-a-connection-by-using-the-easy-connect-naming-method.html#GUID-1035ABB3-5ADE-4697-A5F8-28...

I thought it was odd that those were empty. Note that I just tested with my own clob tables with no problems. If possible, when you create a new file, please use an Iso 8601 date format and UTF-8 for the encoding. That will just make it easier to load.

I can't seem to replicate this issue with OCI 21.8. Anything else I can try to cause it?

Can you create a new thread for the issue that you're talking about with a simple test case? I'll be happy to take a look, but it really needs to be something I can recreate fairly easily. Currently all my Oracle testing is through a free Oracle Cloud account and so the test case needs to be narrowe...

Note that as far as I know, this issue and possible fix just relates to the thread topic. Is there a simple test case for those other issues you mentioned? Granted, that's often the hardest part of tracking down a pointer or buffer issue lol! I'll be happy to take a look as I haven't run across them...

Doing some experimentation, I've noticed the following: This is specific to 64bit and the supposedly 22 byte TOCINumber type. In this case the OCIBind.value_sz is 22 and Zeos does a getmem of exactly 22bytes for that bind buffer. If I change that buffer size to add 2 extra bytes to the end. The memo...

I've included a console program below which when run in 64bit should cause an "A memory block footer has been corrupted." message. This seems to happen with bigdecimals and 64bit. I'm using FastMM5 to test for issues. I haven't been able to detect the source of the issue but data's being w...

Update! I've also now seen it give range check/pointer errors when trying to convert that format. It looks like (and confirmed from the thread you linked to) that those library functions just can't handle multi-char date delimiters. I'm not sure how important that is, since that's a format I've neve...

That's interesting. For me, this call goes into an infinite loop in both 32bit and 64bit debug mode. Delphi 11.3 patch 1. Test := TryUniToTimeStamp('1903. 03. 02.', 13, 'dddd, mmmm d, yyyy', TS); That's odd that it causes a range error for you instead, but I haven't spent a lot of time debugging it....

Zeoslib seems to use FormatSettings.LongDateFormat in the ZDatasetparam unit to convert timestamps. This appears to be incorrect (or at least the default LongDateFormat format string is currently actually a very verbose date only format, perhaps that changed at some point?) On my system it defaults ...

Oops! Good point! Thanks again!

-Mark

Nicely done! Passed all my tests. A very minor point is that I think you may be able to also remove AllocateOracleSQLVars as SetLength *should* be all that's needed and zeroes the memory automatically (should is in asterisks because I don't know if that's always been the case or how Laz/free pascal ...

For the purposes of the size calculation only TZSQLVars would need to be packed as far as I can tell. Sizeof is used on TZSQLVar which will work correctly regardless of alignment. Now I haven't looked closely at how that memory is used, so there could be other reasons that I don't know about for TSQ...