From becoggins at hotmail.com Tue Dec 5 21:44:50 2023 From: becoggins at hotmail.com (Brian E. Coggins) Date: Tue Dec 5 21:35:57 2023 Subject: [odb-users] macOS Sonoma Include (and Lib?) Issues Message-ID: Hi friends, Another macOS upgrade, another set of annoying problems with finding system headers. Sonoma?s clang++ removed some deprecated C++ stuff, breaking my installed version of boost, upgrading boost in homebrew for some reason forced an irreversible gcc update that prevented my old compilation of odb from finding its dynamic libraries, so now I?m trying to recompile odb?and g++-13 can?t find the system headers (and probably libraries, too, but I haven?t gotten that far). As many of us know, Apple has been making this harder and harder with each update, for reasons that are impossible for us mortals to understand. Questions: 1. Does anybody know of a nice and clean solution for the whole system that would allow g++-13 to find the headers with no special magic? It would be brilliant if homebrew gcc knew how to invoke xcrun, but my installation doesn?t seem to know how to do this. Maybe I?m doing something wrong. Any advice appreciated. 2. One web post suggested export SDKROOT="`xcrun --show-sdk-path`? which does brilliantly solve the problem for that terminal session, and can go in .bashrc to make lots of things smooth. However, bpkg doesn?t pay attention to this. I imagine there?s some incantation that could be added to my "bpkg create? call to get the right directories added in? Can anyone share what that might be? Thanks, Brian From becoggins at hotmail.com Tue Dec 5 23:26:39 2023 From: becoggins at hotmail.com (Brian E. Coggins) Date: Tue Dec 5 23:17:43 2023 Subject: [odb-users] Re: macOS Sonoma Include (and Lib?) Issues In-Reply-To: References: Message-ID: Upon further review, I?m thinking that exporting SYSROOT may have helped. I?m no longer getting errors for ordinary C/C++ standard library headers; instead, all of the errors building odb look like this, and specifically involve gmp.h being invoked from system.h: ... error: process g++-13 exited with code 1 info: command line: g++-13 -I/Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/pregenerated -I/Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25 -I/Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25 -I/usr/local/Cellar/gcc/13.2.0/lib/gcc/current/gcc/x86_64-apple-darwin23/13/plugin/include -DODB_GXX_NAME="g++-13" -DODB_BUILD2 -I/Users/brian/Software/odb-build/odb-gcc-13/libcutl-1.11.0-b.9+1 -I/Users/brian/Software/odb-build/odb-gcc-13/libcutl-1.11.0-b.9+1 -DLIBCUTL_SHARED -I/Users/brian/Software/odb-build/odb-gcc-13/libstudxml-1.1.0-b.10+2 -I/Users/brian/Software/odb-build/odb-gcc-13/libstudxml-1.1.0-b.10+2 -DLIBSTUDXML_SHARED -O3 -std=c++23 -fdiagnostics-color -finput-charset=UTF-8 -o odb-2.5.0-b.25/odb/source.dylib.o -c -x c++ /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/source.cxx info: while updating odb-2.5.0-b.25/odb/objs{source} info: while updating odb-2.5.0-b.25/odb/libus{odb} info: while updating odb-2.5.0-b.25/odb/plugin{odb} info: while updating odb-2.5.0-b.25/dir{odb/} info: while updating dir{odb-2.5.0-b.25/} c++ odb-2.5.0-b.25/odb/cxx{common} -> odb-2.5.0-b.25/odb/objs{common} In file included from /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/gcc-fwd.hxx:24, from /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/context.hxx:7, from /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/common.hxx:12, from /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/common.cxx:4: /usr/local/Cellar/gcc/13.2.0/lib/gcc/current/gcc/x86_64-apple-darwin23/13/plugin/include/system.h:703:10: fatal error: gmp.h: No such file or directory 703 | #include | ^~~~~~~ compilation terminated. ? Thoughts? (I also realize I may not have been completely clear in my original message. The problem wasn't that gcc couldn't find headers like iostream and needed a -I flag; homebrew g++-13 can find those out of the box. Rather, the problem is that those headers are stubs that invoke system headers in the Apple SDK, and homebrew gcc didn?t seem to know how to find that Apple SDK. I think the export SYSROOT trick may have solved that for most of the headers. Except, evidently, this gmp.h, whatever that is.) > On 05 Dec 2023, at 21:44, Brian E. Coggins wrote: > > Hi friends, > > Another macOS upgrade, another set of annoying problems with finding system headers. Sonoma?s clang++ removed some deprecated C++ stuff, breaking my installed version of boost, upgrading boost in homebrew for some reason forced an irreversible gcc update that prevented my old compilation of odb from finding its dynamic libraries, so now I?m trying to recompile odb?and g++-13 can?t find the system headers (and probably libraries, too, but I haven?t gotten that far). As many of us know, Apple has been making this harder and harder with each update, for reasons that are impossible for us mortals to understand. > > Questions: > > 1. Does anybody know of a nice and clean solution for the whole system that would allow g++-13 to find the headers with no special magic? It would be brilliant if homebrew gcc knew how to invoke xcrun, but my installation doesn?t seem to know how to do this. Maybe I?m doing something wrong. Any advice appreciated. > > 2. One web post suggested > > export SDKROOT="`xcrun --show-sdk-path`? > > which does brilliantly solve the problem for that terminal session, and can go in .bashrc to make lots of things smooth. However, bpkg doesn?t pay attention to this. I imagine there?s some incantation that could be added to my "bpkg create? call to get the right directories added in? Can anyone share what that might be? > > Thanks, > Brian > From boris at codesynthesis.com Wed Dec 6 06:55:36 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 6 06:46:08 2023 Subject: [odb-users] Re: macOS Sonoma Include (and Lib?) Issues In-Reply-To: References: Message-ID: Brian E. Coggins writes: > error: process g++-13 exited with code 1 > info: command line: g++-13 -I/Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/pregenerated -I/Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25 -I/Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25 -I/usr/local/Cellar/gcc/13.2.0/lib/gcc/current/gcc/x86_64-apple-darwin23/13/plugin/include -DODB_GXX_NAME="g++-13" -DODB_BUILD2 -I/Users/brian/Software/odb-build/odb-gcc-13/libcutl-1.11.0-b.9+1 -I/Users/brian/Software/odb-build/odb-gcc-13/libcutl-1.11.0-b.9+1 -DLIBCUTL_SHARED -I/Users/brian/Software/odb-build/odb-gcc-13/libstudxml-1.1.0-b.10+2 -I/Users/brian/Software/odb-build/odb-gcc-13/libstudxml-1.1.0-b.10+2 -DLIBSTUDXML_SHARED -O3 -std=c++23 -fdiagnostics-color -finput-charset=UTF-8 -o odb-2.5.0-b.25/odb/source.dylib.o -c -x c++ /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/source.cxx > info: while updating odb-2.5.0-b.25/odb/objs{source} > info: while updating odb-2.5.0-b.25/odb/libus{odb} > info: while updating odb-2.5.0-b.25/odb/plugin{odb} > info: while updating odb-2.5.0-b.25/dir{odb/} > info: while updating dir{odb-2.5.0-b.25/} > c++ odb-2.5.0-b.25/odb/cxx{common} -> odb-2.5.0-b.25/odb/objs{common} > In file included from /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/gcc-fwd.hxx:24, > from /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/context.hxx:7, > from /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/common.hxx:12, > from /Users/brian/Software/odb-build/odb-gcc-13/odb-2.5.0-b.25/odb/common.cxx:4: > /usr/local/Cellar/gcc/13.2.0/lib/gcc/current/gcc/x86_64-apple-darwin23/13/plugin/include/system.h:703:10: fatal error: gmp.h: No such file or directory > 703 | #include > | ^~~~~~~ gmp is a dependency of GCC in Homebrew so you should have gotten this header installed (somewhere under /usr/local/) and it normally gets found automatically. At least that worked out of the box up to an including GCC 13.1.0 on Mac OS Ventura 13.4: https://cppget.org/?builds=odb&pv=2.5.0-b.25&tc=macos_*-gcc_13* If you do find gmp.h there, you can try adding a manual -I to its location. > (I also realize I may not have been completely clear in my original > message. The problem wasn't that gcc couldn't find headers like iostream > and needed a -I flag; homebrew g++-13 can find those out of the box. > Rather, the problem is that those headers are stubs that invoke system > headers in the Apple SDK, and homebrew gcc didn?t seem to know how to find > that Apple SDK. I think the export SYSROOT trick may have solved that for > most of the headers. Except, evidently, this gmp.h, whatever that is.) This looks like it's either Homebrew GCC that is broken on Sonoma or your setup is broken (maybe makes sense to do a clean re-install of Homebrew?) If it is the former, then it makes sense to report this to Homebrew (unless it is already reported). If you do file or find an issue for this, please share the link so that we can track it. From becoggins at hotmail.com Wed Dec 6 15:36:39 2023 From: becoggins at hotmail.com (Brian E. Coggins) Date: Wed Dec 6 15:27:44 2023 Subject: [odb-users] macOS Sonoma Include (and Lib?) Issues In-Reply-To: References: Message-ID: On 06 Dec 2023, at 06:55, Boris Kolpackov wrote: > This looks like it's either Homebrew GCC that is broken on Sonoma or your > setup is broken (maybe makes sense to do a clean re-install of Homebrew?) Great advice: a clean re-install of Homebrew solved all of the problems, with no need for SDKROOT or any other special adjustments. I should?ve thought to try that! My first message was hinting that I?ve seen various path problems from Homebrew GCC in the past after updating macOS. Maybe the lesson is that Homebrew doesn?t handle these upgrades well (even with ?brew update? etc), and the general fix should be to start over with a clean Homebrew install. Brian From d.patrushev at prosoftsystems.ru Wed Dec 13 03:55:09 2023 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Wed Dec 13 03:46:00 2023 Subject: [odb-users] arbitrary query returning tuples Message-ID: <11329cbc5fca446992a09f1e577a8a42@prosoftsystems.ru> Hello. The doc says: To support these kinds of use cases, ODB allows us to specify the complete query for a native view at runtime rather than at the view definition. To indicate that a native view has a runtime query, we can either specify the empty db query pragma or omit the pragma altogether. For example: #pragma db view struct sequence_value { unsigned long long value; }; The library in question is libodb-pgqsl. I used to leverage this feature for complex SELECT's that would otherwise be impossible to execute using "normal" odb mechanisms. I figured that this kind of view allowed you to run arbitrary queries returning tuples, but it turns out I was wrong. I found out that it is impossible to run a query, which, for example starts with "INSERT...". I spent some time digging in the sources and realized libodb-pgsql does some preprocessing even for this kind of super low-level view, adding "WHERE" if the text of the query doesn't meet certain criteria, which results in invalid SQL. That was news to me. So, the question is: is that a feature? If it is, is there still a way to execute an arbitrary query returning tuples (for any database backend, not just libodb-pgsql)? From boris at codesynthesis.com Thu Dec 14 03:47:23 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 14 03:37:54 2023 Subject: [odb-users] arbitrary query returning tuples In-Reply-To: <11329cbc5fca446992a09f1e577a8a42@prosoftsystems.ru> References: <11329cbc5fca446992a09f1e577a8a42@prosoftsystems.ru> Message-ID: ???????? ????? ????????? writes: > I spent some time digging in the sources and realized libodb-pgsql > does some preprocessing even for this kind of super low-level view, > adding "WHERE" if the text of the query doesn't meet certain criteria, > which results in invalid SQL. That was news to me. So, the question > is: is that a feature? The reason we do this is because you can either specify the entire query of just the WHERE condition and we need to distinguish these two cases (there is also the stored procedure call complication). The way we do it is by looking for the leading word like SELECT, EXEC, etc. > If it is, is there still a way to execute an arbitrary query > returning tuples (for any database backend, not just libodb-pgsql)? There is a note in odb/relational/processor.cxx:1183: //@@ We need to recognize database-specific list of prefixes. For // example, PG has WITH. Alternatively (or in addition) we could // do the same comment trick (e.g., /*SELECT*/ to treat it as a // SELECT-like queiry). So /*SELECT*/ could be one way to support this. Also, I am actually not sure whether INSERT returns results in the same way as SELECT; that's the compilation I refer to with stored procedure calls -- for some databases the result is returned differently. In fact, you can probably try /*CALL*/ INSERT to see if this maybe already works. From d.patrushev at prosoftsystems.ru Thu Dec 14 06:45:27 2023 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Thu Dec 14 06:36:18 2023 Subject: [odb-users] arbitrary query returning tuples In-Reply-To: References: <11329cbc5fca446992a09f1e577a8a42@prosoftsystems.ru>, Message-ID: 1. But in case of plain #pragma db view (no sql text whatsoever) it is clear that the user has to provide a complete statement, not just a condition, isn't it? 2. Does the /*CALL*/ trick apply to #pragma db view query() views? ________________________________ ??: Boris Kolpackov ??????????: 14 ??????? 2023 ?. 13:47:23 ????: ???????? ????? ????????? ?????: odb-users@codesynthesis.com ????: Re: [odb-users] arbitrary query returning tuples ???????? ????? ????????? writes: > I spent some time digging in the sources and realized libodb-pgsql > does some preprocessing even for this kind of super low-level view, > adding "WHERE" if the text of the query doesn't meet certain criteria, > which results in invalid SQL. That was news to me. So, the question > is: is that a feature? The reason we do this is because you can either specify the entire query of just the WHERE condition and we need to distinguish these two cases (there is also the stored procedure call complication). The way we do it is by looking for the leading word like SELECT, EXEC, etc. > If it is, is there still a way to execute an arbitrary query > returning tuples (for any database backend, not just libodb-pgsql)? There is a note in odb/relational/processor.cxx:1183: //@@ We need to recognize database-specific list of prefixes. For // example, PG has WITH. Alternatively (or in addition) we could // do the same comment trick (e.g., /*SELECT*/ to treat it as a // SELECT-like queiry). So /*SELECT*/ could be one way to support this. Also, I am actually not sure whether INSERT returns results in the same way as SELECT; that's the compilation I refer to with stored procedure calls -- for some databases the result is returned differently. In fact, you can probably try /*CALL*/ INSERT to see if this maybe already works. From d.patrushev at prosoftsystems.ru Thu Dec 14 06:47:59 2023 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Thu Dec 14 06:38:37 2023 Subject: [odb-users] arbitrary query returning tuples In-Reply-To: References: <11329cbc5fca446992a09f1e577a8a42@prosoftsystems.ru>, , Message-ID: <8a1234c1dfff4d2fa1ad6db0a37f01a0@prosoftsystems.ru> >The reason we do this is because you can either specify the entire >query of just the WHERE condition and we need to distinguish these >two cases (there is also the stored procedure call complication). >The way we do it is by looking for the leading word like SELECT, >EXEC, etc. But in case of plain #pragma db view (no sql text whatsoever) it is clear that the user has to provide a complete statement, not just a condition, isn't it? >Also, I am actually not sure whether INSERT returns results in the >same way as SELECT; that's the compilation I refer to with stored >procedure calls -- for some databases the result is returned >differently. In fact, you can probably try /*CALL*/ INSERT to >see if this maybe already works Does the /*CALL*/ trick apply to #pragma db view query() views? ________________________________ ??: ???????? ????? ????????? ??????????: 14 ??????? 2023 ?. 16:45:27 ????: odb-users@codesynthesis.com ????: Re: [odb-users] arbitrary query returning tuples 1. But in case of plain #pragma db view (no sql text whatsoever) it is clear that the user has to provide a complete statement, not just a condition, isn't it? 2. Does the /*CALL*/ trick apply to #pragma db view query() views? ________________________________ ??: Boris Kolpackov ??????????: 14 ??????? 2023 ?. 13:47:23 ????: ???????? ????? ????????? ?????: odb-users@codesynthesis.com ????: Re: [odb-users] arbitrary query returning tuples ???????? ????? ????????? writes: > I spent some time digging in the sources and realized libodb-pgsql > does some preprocessing even for this kind of super low-level view, > adding "WHERE" if the text of the query doesn't meet certain criteria, > which results in invalid SQL. That was news to me. So, the question > is: is that a feature? The reason we do this is because you can either specify the entire query of just the WHERE condition and we need to distinguish these two cases (there is also the stored procedure call complication). The way we do it is by looking for the leading word like SELECT, EXEC, etc. > If it is, is there still a way to execute an arbitrary query > returning tuples (for any database backend, not just libodb-pgsql)? There is a note in odb/relational/processor.cxx:1183: //@@ We need to recognize database-specific list of prefixes. For // example, PG has WITH. Alternatively (or in addition) we could // do the same comment trick (e.g., /*SELECT*/ to treat it as a // SELECT-like queiry). So /*SELECT*/ could be one way to support this. Also, I am actually not sure whether INSERT returns results in the same way as SELECT; that's the compilation I refer to with stored procedure calls -- for some databases the result is returned differently. In fact, you can probably try /*CALL*/ INSERT to see if this maybe already works. From pengfei8244 at gmail.com Thu Dec 14 22:08:59 2023 From: pengfei8244 at gmail.com (Fei Peng) Date: Fri Dec 15 06:27:41 2023 Subject: [odb-users] Can we use odb::query and odb::persist outside of transactions? Message-ID: Can we use odb::query and odb::persist outside of transactions? Or will future versions provide related support? Some scenarios do not require transactions, such as simple read/write single data. Forcing transactions to add additional performance overhead and increase the risk of locking tables. From finjulhich at gmail.com Sat Dec 16 09:27:45 2023 From: finjulhich at gmail.com (MM) Date: Sat Dec 16 09:18:46 2023 Subject: [odb-users] again: bad value ('/dev/null') for '-mtune=' switch Message-ID: Referring to earlier threads on this error, it seems the solution is to rebuild odb. Now, I've upgraded from Fedora38 to 39, and that upgraded g++ from 13.2.1 20231011 (Red Hat 13.2.1-4) to 13.2.1 20231205 (Red Hat 13.2.1-6) I would have guessed that this would not require a odb rebuild. Strange The cc1plus invocation that fails is cc1plus -quiet -v -mtune=generic -mtune=generic -march=x86-64 -Wunknown-pragmas -Wno-deprecated -std=c++17 -version -o -.s This last argument -.s seems incorrecT? From finjulhich at gmail.com Sat Dec 16 09:36:38 2023 From: finjulhich at gmail.com (MM) Date: Sat Dec 16 09:27:38 2023 Subject: [odb-users] Re: again: bad value ('/dev/null') for '-mtune=' switch Message-ID: Referring to earlier threads on this error, it seems the solution is to rebuild odb. Now, I've upgraded from Fedora38 to 39, and that upgraded g++ from 13.2.1 20231011 (Red Hat 13.2.1-4) to 13.2.1 20231205 (Red Hat 13.2.1-6) I would have guessed that this would not require a odb rebuild. Strange The cc1plus invocation that fails is cc1plus -quiet -v -mtune=generic -mtune=generic -march=x86-64 -Wunknown-pragmas -Wno-deprecated -std=c++17 -version -o -.s This last argument -.s seems incorrecT? This below which didn't really do anything except relink and reinstall fixed the problem in this case. bpkg uninstall odb $ bpkg build --upgrade --recursive odb $ bpkg install odb From boris at codesynthesis.com Mon Dec 18 04:45:46 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 18 04:36:12 2023 Subject: [odb-users] Re: again: bad value ('/dev/null') for '-mtune=' switch In-Reply-To: References: Message-ID: MM writes: > Now, I've upgraded from Fedora38 to 39, and that upgraded g++ from > > 13.2.1 20231011 (Red Hat 13.2.1-4) > > to > > 13.2.1 20231205 (Red Hat 13.2.1-6) > > I would have guessed that this would not require a odb rebuild. ODB is implemented as a GCC plugin and GCC does not have any API stability guarantees for plugins, not even between patch-releases. So it's always wise to rebuild ODB after upgrading GCC. From boris at codesynthesis.com Mon Dec 18 04:51:00 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 18 04:41:25 2023 Subject: [odb-users] Can we use odb::query and odb::persist outside of transactions? In-Reply-To: References: Message-ID: Fei Peng writes: > Can we use odb::query and odb::persist outside of transactions? Or will > future versions provide related support? Some scenarios do not require > transactions, such as simple read/write single data. Forcing transactions > to add additional performance overhead and increase the risk of locking > tables. While you did not specify which database you are using (always a good idea), none of the databases ODB currently supports can perform the operations in question without requiring a transaction. They can be performed in implicit transactions (i.e., the transaction is started automatically immediately before the operation and committed immediately after), but there is always a transaction. While it's true an implicit transaction may have a slightly better performance in certain situations (because there is no need for explicit BEGIN/COMMIT statements), they are also very error-prone and we currently have no plans to support them in ODB. From roberto.minarelli.de at gmail.com Thu Dec 21 10:39:46 2023 From: roberto.minarelli.de at gmail.com (roberto minarelli) Date: Fri Dec 22 08:53:05 2023 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 Message-ID: Hi, I've already searched all the archive but I could not find anything I am trying to inserting a in a column specified as CLOB more than 12288 chars, that appears to be the actual limit I am using the odb version 2.5.0-b.23 on OS OL 8.7 having g++ version 8.5.0 the class is as follows: #pragma db value class PamExchangeId { #pragma db column("UUID") type("VARCHAR2(40)") std::string strUUID; #pragma db column("OPERATION_TYPE") unsigned short usOperationType; friend class odb::access; public: PamExchangeId(std::string uuid="", unsigned short operation=0) { strUUID=uuid; usOperationType=operation; } virtual ~PamExchangeId(){} std::string getUUID()const {return strUUID;} unsigned short getOperationType() const {return usOperationType;} void setUUID(const std::string& value) {strUUID=value;} void setOperationType(unsigned short value) {usOperationType=value;} bool operator<(const PamExchangeId key) const { return strUUID.compare(key.getUUID()) <0 || (strUUID.compare(key.getUUID()) == 0 && usOperationType < key.getOperationType()); } }; #pragma db object table("MPVR_DBA.VR_SDG_PAM_EXCHANGE") class VRSdgPamExchange { #pragma db id column("") PamExchangeId Id; #pragma db type("CLOB") column ("SDG_PAM_JSON_REQUEST") std::string strSdgPamJsonRequest; #pragma db type("CLOB") column ("SDG_PAM_JSON_RESPONSE") std::string strSdgPamJsonResponse; #pragma db column ("MILLIS") unsigned long ulMillis; #pragma db column ("LAST_UPDATE") type("DATE") std::string strLastUpdate; #pragma db index ("PK_VR_SDG_PAM_EXCHANGE") unique members(Id) friend class odb::access; public: VRSdgPamExchange(){} virtual ~VRSdgPamExchange() {} void setId(PamExchangeId& value) {Id=value;} void setSdgPamJsonRequest(const std::string& value) {strSdgPamJsonRequest=value;} void setSdgPamJsonResponse(const std::string& value){strSdgPamJsonResponse=value;} void setMillis(const unsigned long value) {ulMillis=value;} void setLastUpdate(const std::string& value) {strLastUpdate=value;} PamExchangeId getId() const {return Id;} std::string getSdgPamJsonRequest() const {return strSdgPamJsonRequest;} std::string getSdgPamJsonResponse() const {return strSdgPamJsonResponse;} unsigned long getMillis() const {return ulMillis;} std::string getLastUpdate() const {return strLastUpdate;} }; The error returned is ORA-01461: can bind a LONG value only for insert into a LONG column may you give me a hint on how to proceed? As I mentioned before, I didn't find anything in the documentation or in the archive Thanks a lot Best Regards! Roberto Minarelli Della Valle From boris at codesynthesis.com Fri Dec 22 09:24:55 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 22 09:27:43 2023 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: roberto minarelli writes: > I am trying to inserting a in a column specified as CLOB more than 12288 > chars, that appears to be the actual limit > > ORA-01461: can bind a LONG value only for insert into a LONG column I don't believe you should be getting this error when trying to insert this amount of data into CLOB. I suspect you are trying to insert it (perhaps by mistake) into, for example, a VARCHAR2 column. I would suggest that you create a separate test with a single object that contains a single column of the CLOB type (plus the id column) and try this. If you are able to insert more than 12288 characters in this test, then there is something wrong with your application. Also see: https://stackoverflow.com/questions/9156019/ora-01461-can-bind-a-long-value-only-for-insert-into-a-long-column-occurs-when/14497831