Forum Stats

  • 3,770,480 Users
  • 2,253,121 Discussions
  • 7,875,481 Comments

Discussions

OraOLEDB is still crazy

User_J1GBE
User_J1GBE Member Posts: 84 Blue Ribbon
edited Jun 10, 2020 12:00AM in Oracle Provider for OLE DB

https://community.oracle.com/message/12990330#12990330

If there is no way to reply to archived discussions,

they don't seem to know that they tend to waste much time more than 120 days to solve the problems of their products.

(The reason why they archive discussions might be because they might know that the problems would be never solved.)

----

> In THIS APRIL(after March, 2015), we built the LATEST(*) 11.2.0.4 client environment.

> As a result, we found new behavior of OraOLEDB...

In the end of THIS SEPTEMBER, we build LATEST(*) 11.2.0.3 client environment.

*)You should ask Oracle Support how to update 11.2.0.3 client to latest revision.

As a result, we found new behavior of OraOLEDB...

---- our result ----

Name|Replace(Value," ","B")|DefinedSize|Type

EQ|ああ|2|202

LT|ああ|4|202

----

They seem to stop appending crazy blanks at last.

The value "202" of "Type" means "adVarWChar".

The number of characters of the value of CHAR(4 BYTE) is "less than or equal to" 4(VARIABLE-characters)

even though the number of bytes of the value is "just equal to" 4(FIXED-bytes)

when the encoding is JA16SJISTILDE(VARIABLE-width 2 byte character set).

Had they recovered their senses?

Not yet.

Why do they still believe that DefinedSize of "EQ" must be "2"?

Why do they cause inconsistencies to cause inconsistencies?

«13

Answers

  • User_J1GBE
    User_J1GBE Member Posts: 84 Blue Ribbon
    edited Jan 26, 2016 12:46AM

    > they don't seem to know that they tend to waste much time more than 120 days

    > to solve the problems of their products.

    The discussion have to be updated periodically to prevent it from being archived.

    The problem is not solved yet.

    Possibly they might not be able to solve it.

    ----

    > select

    > case when 1=1 then 'ああ' else 'XXXX' end EQ,

    > case when 1<2 then 'ああ' else 'XXXX' end LT

    > from DUAL

    > Name|Replace(Value," ","B")|DefinedSize|Type

    > EQ|ああ|2|202

    > LT|ああ|4|202

    In OraOLEDB 11.2.0.3.latest,

    the values of "EQ" and "LT" are always equal to 'ああ'.

    However the DefinedSize of them are different from each other.

    ----

    > Why do they still believe that DefinedSize of "EQ" must be "2"?

    They seem to believe that not they but customer is responsible for the difference,

    even if customer advises to stop deceiving before changing and they ignore the advice,

    even if customer advises to stop releasing after changing and they ignore the advice.

    ----

    > Why do they cause inconsistencies to cause inconsistencies?

    They seem to believe that a customer should waste his support incidents for THEM.

    It seems that they make mistakes (intentionally) to force customers to waste support incidents, of course it must not be true though.

  • User_J1GBE
    User_J1GBE Member Posts: 84 Blue Ribbon
    edited May 16, 2016 12:49AM

    > there is no way to reply to archived discussions

    We have to update this discussion to prevent it from being archived.

    > EQ|ああ|2|202

    > LT|ああ|4|202

    We want to believe they believe the inconsistency should be solved.

    > case when 1=1 then 'ああ' else 'XXXX' end EQ,

    > case when 1<2 then 'ああ' else 'XXXX' end LT

    When the character set is JA16SJISTILDE, the lengths of 'ああ' and 'XXXX' are equal to 4 in bytes semantics.

    They are 4 or fewer in char semantics.

    > The value "202" of "Type" means "adVarWChar".

    > Why do they still believe that DefinedSize of "EQ" must be "2"?

    We can understand the length should be variable in char semantics.

    In the above case, we believe the maximum number of characters should be 4.

  • User_J1GBE
    User_J1GBE Member Posts: 84 Blue Ribbon
    edited Sep 2, 2016 2:14AM

    > The discussion have to be updated periodically to prevent it from being archived.

    ----

    The data type "CHAR" means fixed-length.

    However the number of CHARACTERS of a value of CHAR(n BYTE) is NOT fixed when the encoding is a MBCS(Variable-Width).

    Is it a defect caused by the OLE DB Spec?

    No, it's not a defect.

    This behavior is by design of CHAR(n BYTE).

    It has nothing to do with the OLE DB Spec.

    ----

    They should understand how to treat a data type in the OLE DB Spec

    when the number of CHARACTERS of a value of the data type is not fixed.

    However it seems they had already understood how to treat VARCHAR2(n CHAR).

    What's the way they fail to treat CHAR(n BYTE)?

    ----

    > As a result, we found new behavior of OraOLEDB...

    > The value "202" of "Type" means "adVarWChar".

    When the provider change run-time metadata,

    it should also change compile-time metadata.

    Microsoft linked server may throw Msg 7356

    when it finds difference of metadata between compile-time and run-time.

  • User_J1GBE
    User_J1GBE Member Posts: 84 Blue Ribbon
    edited Dec 8, 2016 9:11PM

    > The discussion have to be updated periodically to prevent it from being archived.

    ----

    We can not understand Oracle Corporation.

    They seem to want to keep the issues.

    They seem to believe that they are allowed to close the SR whenever they want to do so, saying that the issue will never be solved.

    On the other hand, they seem to continue modifying their producsts to produce new problems.

    They seem to believe that their products are allowed to return strange data or to cause errors in other(MS) products.

    We had told them that their product can cause Msg 7356 before they filed new bug document.

  • User_J1GBE
    User_J1GBE Member Posts: 84 Blue Ribbon
    edited Mar 29, 2017 12:57AM

    > The discussion have to be updated periodically to prevent it from being archived.

    I keep preventing this discussion from being archived because I will update it when the problem will be resolved someday.

    ----

    If you have an Oracle Support account, you can see related documents.

    https://community.oracle.com/thread/4026577

    > ORACLE fails to handle CHAR(n BYTE) with OraOLEDB

  • User_J1GBE
    User_J1GBE Member Posts: 84 Blue Ribbon
    edited Jul 12, 2017 8:33PM

    The 120 days is too short for them to solve their problems. SR has no progress.
    Reviving archived discussions.

  • User_J1GBE
    User_J1GBE Member Posts: 84 Blue Ribbon
    edited Nov 7, 2017 4:58AM

    > The discussion have to be updated periodically to prevent it from being archived.

    They still seem to be waiting for internal response.

  • EdStevens
    EdStevens Member Posts: 28,536 Gold Crown
    edited Nov 7, 2017 9:04AM
    2833196 wrote:> The discussion have to be updated periodically to prevent it from being archived.They still seem to be waiting for internal response.

    So what are you expecting from a community of volunteers, that you keep 'bumping' this thread.

    I think this is starting to border on 'abuse'.

  • User_J1GBE
    User_J1GBE Member Posts: 84 Blue Ribbon
    edited Nov 8, 2017 11:22PM

    > They still seem to be waiting for internal response.

    "They" does not mean "volunteers of this community" here.

    "They" responded us that they are waiting.

    We don't know whether it's true or not, though.

    ----

    > what are you expecting from a community

    This community should give users the way to unarchive the thread.

    If it could not, it should not archive the thread that is still under investigation.

    > that you keep 'bumping' this thread.

    What is the way a community knows whether a thread is still under investigation or not?

    If there is a way to indicate the thread is still under investigation and the way never bump-up the thread, we will use the way.

    We expect threads have their conclusions.

    So we will give this thread some conclusion in the future.

    Do you expect this community will be filled with unconcluded threads?

  • EdStevens
    EdStevens Member Posts: 28,536 Gold Crown
    edited Nov 9, 2017 9:04AM
    2833196 wrote:> They still seem to be waiting for internal response."They" does not mean "volunteers of this community" here."They" responded us that they are waiting.We don't know whether it's true or not, though.----> what are you expecting from a communityThis community should give users the way to unarchive the thread.If it could not, it should not archive the thread that is still under investigation.> that you keep 'bumping' this thread.What is the way a community knows whether a thread is still under investigation or not?If there is a way to indicate the thread is still under investigation and the way never bump-up the thread, we will use the way.We expect threads have their conclusions.So we will give this thread some conclusion in the future.Do you expect this community will be filled with unconcluded threads?

    The community is already filled with "unconcluded" threads.

    You've been beating on this for over 2 years now.  You indicated earlier that you had an SR to address your original problem.  If you are not satisfied with the result of that SR, you need to take it up with Oracle Support, not the public forum.  There is absolutely nothing anyone here can do to resolve your problem your problem with OLEDB, and your problem with the way the community is administered is a problem only to you.

    So how has your periodic bumping of the thread worked out for you so far?  Has it gotten you any closer to a resolution?

    The definition of insanity is doing the same thing over and over again and expecting a different result.