Discussions
Categories
- 382.3K All Categories
- 2.1K Data
- 209 Big Data Appliance
- 1.9K Data Science
- 448K Databases
- 221K General Database Discussions
- 3.7K Java and JavaScript in the Database
- 25 Multilingual Engine
- 520 MySQL Community Space
- 467 NoSQL Database
- 7.8K Oracle Database Express Edition (XE)
- 2.9K ORDS, SODA & JSON in the Database
- 492 SQLcl
- 3.9K SQL Developer Data Modeler
- 186.2K SQL & PL/SQL
- 21K SQL Developer
- 293.3K Development
- 7 Developer Projects
- 128 Programming Languages
- 290K Development Tools
- 95 DevOps
- 3K QA/Testing
- 645.5K Java
- 24 Java Learning Subscription
- 36.9K Database Connectivity
- 150 Java Community Process
- 104 Java 25
- 22.1K Java APIs
- 137.9K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 16 Java Essentials
- 144 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 198 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 267 LiveLabs
- 36 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.8K Other Languages
- 2.3K Chinese
- 166 Deutsche Oracle Community
- 1.2K Español
- 1.9K Japanese
- 230 Portuguese
OraOLEDB is still crazy
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?
Answers
-
> 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.
-
> 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.
-
> 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.
-
> 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.
-
> 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
-
The 120 days is too short for them to solve their problems. SR has no progress.
Reviving archived discussions. -
> The discussion have to be updated periodically to prevent it from being archived.
They still seem to be waiting for internal response.
-
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'.
-
> 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?
-
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.