Re: Any way to capture spatial bind data?

Thanks Rajeev and Jonathan for your help. I will request a client driver update.

Regards,
Osman

Jonathan Lewis <jlewisoracle_at_gmail.com>, 9 Ara 2023 Cmt, 20:52 tarihinde şunu yazdı:

>
> Following up on Rajeev's comment about drivers - is it possible that
> someone is using an older version of the JDBC driver.
> You may have gone through all this already, but I just did a quick search
> on MOS for: TTC ORA-03137, and one of the first notes in the list was:
>
> ORA-03137: malformed TTC packet from client rejected: [3146] [94] [] [] []
> [] [] [] While Using JDBC 12.2.0.1 (Doc ID 2519886.1)
>
> The root cause if fixed in JDBC 18.3
>
> Regards
> Jonathan Lewis
>
>
>
> On Sat, 9 Dec 2023 at 15:58, Osman DINC <dinch.osman_at_gmail.com> wrote:
>
>> Thanks Jonathan for your time.
>>
>> I will check with disabling ASO (Advanced Security Option) parameters and
>> try a client level tracing using TRACE_LEVEL_CLIENT parameter in sqlnet.ora
>> if it helps. Also I will coordinate with the application team if they can
>> catch it in the app layer.
>>
>> Regards,
>> Osman DİNÇ
>>
>>
>>
>> Jonathan Lewis <jlewisoracle_at_gmail.com>, 9 Ara 2023 Cmt, 14:44 tarihinde
>> şunu yazdı:
>>
>>> I had a little play around with this, but I couldn't find a way to get
>>> at the bind value.
>>>
>>> The 10046 trace shows only the first 16 bytes of the raw data.
>>> (Interesting detail - I was using a simple rectangle as the bind
>>> sdo_geometry), on disc it took about 90 bytes, but the bind variable was
>>> declared as 656 bytes.
>>>
>>> I tried dumping the error stack at level 3, and still couldn't find the
>>> bind, all I got was the same description, pointer and 16 bytes.
>>>
>>> It did occur to me that even if I found a way to dump the (whole) bind
>>> we still might not see it for this error if the error is occurring in the
>>> SQL*Net transport layer before it gets to the session layer that we
>>> normally trace. I've probably missed or forgotten some dump/trace we could
>>> invoke, but I think it would be a case of dumping the entire session state
>>> when the error occured then finding the short description of the bind and
>>> following the pointer into the full memory dump of the session. Possibly
>>> someone else will be able to suggest a way of doing that.
>>>
>>> One simple guess - an SDO_GEOMETRY includes two declarations of
>>> varray(1048576) of number (stored as LOBs). Maybe the particular value that
>>> causes the problem is just too large for some part of the code that is
>>> trying to handle it. It might be worth checking where the bind values come
>>> from, and checking to see if there are any very large LOB values stored in
>>> the table.
>>>
>>>
>>> Regards
>>> Jonathan Lewis
>>>
>>>
>>>
>>> On Fri, 8 Dec 2023 at 07:26, Osman DINC <dinch.osman_at_gmail.com> wrote:
>>>
>>>> Hi Jonathan;
>>>>
>>>> Error is like below:
>>>>
>>>> Database version is 19.20.
>>>>
>>>> ORA-03137: malformed TTC packet from client rejected[3146] [94] [] []
>>>> [] [] [] []
>>>> ORA-03146: invalid buffer length for TTC field.
>>>>
>>>> sql statement is like below: (fully replaced)
>>>>
>>>> SELECT V_EW_ORG_DEVICE.DEVICE_ID,
>>>> V_EW_ORG_DEVICE.PAR_ORG,
>>>> V_EW_ORG_DEVICE.ORG_ID,
>>>> V_EW_ORG_DEVICE.ORG_NAME,
>>>> V_EW_ORG_DEVICE.SYS_ID,
>>>> V_EW_ORG_DEVICE.SYS_NAME,
>>>> V_EW_ORG_DEVICE.SYS_TASK_TYPE,
>>>> V_EW_ORG_DEVICE.SYS_TASK,
>>>> V_EW_ORG_DEVICE.SYS_DESC,
>>>> V_EW_ORG_DEVICE.SYS_SER_NU,
>>>> V_EW_ORG_DEVICE.OP1,
>>>> V_EW_ORG_DEVICE.OP1_NAME,
>>>> V_EW_ORG_DEVICE.OP1_PHONE,
>>>> V_EW_ORG_DEVICE.OP1_ORG,
>>>> V_EW_ORG_DEVICE.OP2,
>>>> V_EW_ORG_DEVICE.OP2_NAME,
>>>> V_EW_ORG_DEVICE.OP2_PHONE,
>>>> V_EW_ORG_DEVICE.OP2_ORG,
>>>> V_EW_ORG_DEVICE.TRANS,
>>>> V_EW_ORG_DEVICE.GEOG_LATI,
>>>> V_EW_ORG_DEVICE.GEOG_LONG,
>>>> V_EW_ORG_DEVICE.DEC_LATI,
>>>> V_EW_ORG_DEVICE.DEC_LONG,
>>>> V_EW_ORG_DEVICE.GEO
>>>> FROM V_EW_ORG_DEVICE
>>>> WHERE ( V_EW_ORG_DEVICE.SYS_NAME = 'ORANGE A'
>>>> OR V_EW_ORG_DEVICE.SYS_NAME = 'ORANGE B')
>>>> AND (sdo_filter (V_EW_ORG_DEVICE.GEO, *:1*) = 'TRUE');
>>>>
>>>> V_EW_ORG_DEVICE.GEO column type is SDO_GEOMETRY
>>>>
>>>> Error is thrown according to the* :1* parameter bind value. But this
>>>> value is not logged in the application layer. And i am curious about is
>>>> there a way to capture SPATIAL bind data.
>>>>
>>>> Thanks.
>>>>
>>>> Osman DINC <dinch.osman_at_gmail.com>, 7 Ara 2023 Per, 20:19 tarihinde
>>>> şunu yazdı:
>>>>
>>>>>
>>>>>
>>>>> Hi Jonathan,
>>>>>
>>>>> I will supply more information tomorrow morning.
>>>>>
>>>>> Regards
>>>>> Osman Dinç
>>>>>
>>>>

--
http://www.freelists.org/webpage/oracle-l