Accessing string object members 'accumulates' errors.

[y-maltsev]

Hello,
This is connected to fix #132. With the test data from it I've encountered a new, problem.

After the fix it seems that when accessing string object members the current code 'accumulates' some kind of error until it crashes.

Its a bit hard to set a precise reproduction case due to it's strange behaviour.

With user 'dmc' I've created the following types:

create type base_t as object (id number, name varchar(12)) not final;
create type derived_2_t under base_t( expl varchar(31)); 

The connection is with the same user:

   Connection con("testDB", "dmc", "dmc");
   Statement st1(con);
   Statement st2(con);
   Object objIO1(TypeInfo(con, "dmc.base_t", TypeInfo::Type));
   Object objIO2(TypeInfo(con, "dmc.derived_2_t", TypeInfo::Type));
   ostring name, expl;

   st1.Prepare("begin :objIO:=dmc.base_t (79,'xxx'); end;");
   st1.Bind(":objIO",objIO1,BindInfo::Out);
   st1.ExecutePrepared();
   name = objIO1.Get<ostring>("name");
   std::cerr<<name<<std::endl;
   // xxx

   st2.Prepare("begin :objIO:=dmc.derived_2_t (79,'xxx','123'); end;");
   st2.Bind(":objIO",objIO2,BindInfo::Out);
   st2.ExecutePrepared();
   name = objIO2.Get<ostring>("expl"); // runtime error
   std::cerr<<objIO2.ToString()<<std::endl; // runtime error

Possibly, you might not be able to reproduce it at your side with this example as it has strange behaviour - if objIO1 is noted to be with type 'base_t' instead of 'dmc.base_t' then this test case ends without errors. In larger program however, with multiple types and their inherited subtypes, this is is not a protection.

Additional note: If we don't get the 'name' value from objIO1, the test case ends without errors. In general, if no string members are accessed or if we don't try to access string members from the subtypes, larger programs seem to work fine.

Considering your outstanding reaction time from #132 , I hope to hear from you soon.

Best Regards,
Yani

[vrogier]

Hi,

I will check this issue either this evening or by tomorrow.

Regards,

Vincent

[vrogier]

Hi,

The issue was happening when trying to access to derived type members while base type cached information was already computed (stupid unnecessary check in my previous commit).
This is now fixed.

Regards,

Vincent

[vrogier]

ocilib::Object::ToString() behavior in #132 was not correct as it was not throwing an exception (number field conversion error due to an invalid offset computation).
I've fixed root cause of #132 and #133 but ocilib::Object::ToString() behavior was still not correct in case of failure.
Thus I've creae issue #134 and committed a fix for it. Thus if there is any other issues in trying to access/convert ocilib::Object members, you will get now the expected C++ exception

[y-maltsev]

Hi Vrogier,

I just want to say, thank you for your hard work on this.
I really appreciate it.

Best regards.