HI Megan,
I did not get your email.
-John
Hi John,
i ran into the same issue as Megan. We used Toad 14.0 until last week and started to use 14.2 since monday. Now we got this issue with chinese signs in clobs. I tested the behaviour in 14.2, 15.1 and 16.0.53. The issue exists in all versions. I wrote a small script to setup a table with some example content to test it. I can reliable reproduce the issue on this example.
Just start the script and open the created table test_clob in schema browser. Then double click the clob field and edit the content. After pushing the "Post edit" a couple of lines at the end disappear and one of the larger rows include chinese signs.
We noticed, that the behaviour is depending on the number of signs we add clob.
Adding the string '1234567890' in row 5 gets chinese signs while adding '123456789' doesnt.
I included my script. Wich user files do you need to analyse this?
We are using a 19c database with WE8MSWIN1252 Encoding. I tested with oracle client 12.2.0.1.0 and 19.3.0.0.0.
Best regards
Dennis
CLOB Fehler.sql (91.6 KB)
Hi Dennis,
Thank you for the script and clear steps to reproduce the problem. That helps a lot. I don't need other files from you.
I can reproduce it. If I follow your steps, I see the corrupt data after hitting "post". But if I hit "Refresh" after that, the data looks as expected and the change that I made is applied correctly.
Do you see the same thing?
There is still a possibility of corruption if you make edits, hit post, then make further edits and post again. But I think you can always work around it by hitting "Refresh" before making edits.
I'll look at this today and hopefully will have a fix for 16.0.
Thanks.
-John
Hi John,
i could verify your desctiption. After hitting refresh the content is correctly displayed and stored.
I am looking forward for the new beta.
Thanks
Dennis
I did some digging and it seems to be a bug in our 3rd party oracle access components. I doubt if they will have a fix for it that we can apply before Toad 16.0 is released.
But since we have a workaround...
I put in a change for next beta that will automatically do a refresh when you post data in a dataset containing CLOBs on a non-unicode database. It seems to work well.
I also added an option under Options -> Data Grids -> Data where this behavior can be disabled, just incase it causes problems for anyone.
Sounds good. I will check that in the next beta and give you a feedback.
I installed the new beta and tried to reproduce the error. I was not able to get any chinese signs.
1 Like
Hi John - My apologies, I don't get notifications of replies so didn't see that my email didn't get through. Many thanks d.reddin for the test case.
I'm currently running Beta 16.0.83.1506 and using the test_clob table and data in the example, I'm still seeing an issue.
Open the popup editor, and you can see 12 lines of data - everything on screen looks fine. Now press Ctrl-End (don't make any edits at all) to go to the end of the data - on mine the data is already displayed as corrupted. I tried toggling between word wrap before I moved to the end of the data, but it's behaving the same for me either way.
Thanks,
Megan
Hi Megan,
I just tried it again - it's not happening anymore for me with D.Reddin's test case.
What is your client and DB versions, and what is the DB character set?
Also, just curios - since you are on the latest beta, does it help if you try the clientless connection?
To do that, before you make the connection from the login window, uncheck "Connect Using Oracle Client"
-John
Hi John,
I've just updated to the latest Beta 16.0.86.1505. I've validated that connecting using the Oracle Client 12.1.0.1.0 I still see the invalid characters. This is my popup:
But, trying the Clientless Connection it looks perfect:
The instances and character sets I have are 19.0.0.0.0 WE8MSWIN1252 and 11.2.0.4 WE8ISO8859P1
So looks like an Oracle client issue?
Thanks,
Megan
Some further info ..
I've just installed the 19.3.0.0 Oracle client - same corruption unfortunately.
HI Megan,
Using the latest beta, I tested several clients:
12.1.0.1 Instant client
12.2 full client
19.13 instant client - won't connect (packet not received error)
18.5 instant client
21.3 instant client
They all worked OK for me (except the one that wouldn't connect).
I double-clicked the CLOB, scrolled down, made an edit, posted, scrolled down, and it still looked ok.
My DB Charset is WE8ISO8859P1 (11.2.0.4)
For the non-instant client, my NLS_LANG is AMERICAN_AMERICA.WE8MSWIN1252. I'm not sure if that is relevant or not.
Sorry, I wish I could reproduce this so I'd have something to fix, but I can't. 
I still have the support case open with our 3rd party Oracle access component (because I still can reproduce it without the "internal refresh after post" workaround that I added a few betas ago). Hopefully they will have a solution soon. I'm glad it at least works for you in no-client mode. I've found no-client mode to be pretty solid, actually. It seems to be a little faster than using a client too. The only problem I've seen with it, is that timestamps have the wrong time zone applied for some users (I have a support case open on that one too).
oh, one thing you can do....double-check and make sure that you have this option checked:
