Toad World® Forums

Double clicking on clob column values (in SB or Editor) where there are 10+ mb of data hangs toad


I have noticed that it is quite a hassle to view clob data by double clicking onto it, since when the size of that specific row is more than 10+mb, then toad basically hangs, sometimes I wait for 5-10 minutes and then it finally loads that data. But very often, it does not happen at all.
Viewing Session Browser from another toad program, shows actually that the session is inactive and does not do any work - hence seems like hanged.

I have tried viewing it from Schema Browser and also via Editor, by writing select query.

On the contrast, when clicking onto "Export dataset" - and using this to extract Clob rows - this is works quite well, even 20-30+MB Clob data can be extracted within seconds.

This has been problem to me for a quite long time, so definetly not a problem for the past few releases.


Hi Raul,

I am about to stop for the day but I just set a reminder to check on this tomorrow.

I appreciate your flurry of minor issues that you've brought up lately. Really, I'm not being sarcastic. I enjoy getting things fixed, but I can't fix them if I don't know about them. So thank you. Keep 'em coming.


1 Like

I just loaded 20Mb worth of data into the popup editor. It took about 5 seconds.

Are you using XML data or anything else that is syntax-highlighted in the popup?

XML usually yes.

How did you try, when all data was in single row or data was distributed on multiple rows?



I made a copy of c:\WIndows\servicing\Sessions.XML and am using that. It is 20Mb.

XML takes a little longer but it still isn't bad for me. It helps to set syntax highlighting to plain text.

Posting changes to the data takes the longest. I don't know if I'll be able to improve that but I'm looking.

How much longer..?
If you compare 20MB plain text file vs xml file, what would be the difference..?

Try with single line also and with xml.

Just thinking, can't there be an issue, so that toad wanting to access internet to validate this xml somehow..? (our toad is in company intranet, we have created registry entry to restrict internet though)



Well, it's still coming up in about 5 seconds but scrolling around is sluggish until I turn syntax highlighting off. Posting takes about a minute either way.

We aren't doing any validating.

Can you email me a large single line XML file? I don't have one handy.


Nevermind, I found a 12Mb, single line XML file. It is much slower.

How much slower this 12MB opened up..?

I just tried with 711527 character xml text (oneliner) (so about 700kb), and it took more than minute to open.

Where is the option to turn syntax higlighting off..?
And can I just turn syntax higlight off for xml only..? (so that sql syntax hilighting is still ON..?)


Looks like this oneliner is the issue yeah.

I loaded this 700kb file into database before modifying the xml text so that it is not oneliner anymore, then it opened up within second.

With the oneliner xml, I can not even click onto any buttons there (for example save to file etc..) or scroll horizontally or nothing - everything laggs.


The popup editor took several minutes to become responsive when 12Mb of data was all on the same line. I think that is the key here. If your XML is formatted, it should be a lot faster.

Are you storing it in CLOB or XMLTYPE columns? If XMLTYPE, go to main Toad options -> Data Grids -> Data. On the right, there is an option "Cast XMLTYPE to CLOB using..." If you set it to XMLSerialize, the XML data will be formatted, which should help. Note: If you change this option while a query with XMLTYPE is active, you'll have to re-execute your query for the change to take effect.

If you are storing as CLOB...there is no way to get it formatted here.

To turn off Syntax Highlighting, right-click, choose this. But the setting doesn't stick. So it's not going to help you with load times. I need to investigate a little more how much that really helps. If it's significant, I could make that an option for the setting to stick.


Yeap, I can confirm oneliner xml is the culprit here. By the way, when I remove first start tag "<" from this text, then this text starts with:

?xml version="1.0" encoding="utf-8"?><s:Envelope ..........

And loading this oneliner text into the database, then it does not do syntax highlight and then it is all good for me. Opens up within second.

We are storing it into CLOB columns.

Yeap, thanks. Glad it is reproducible.
I'll leave you to it.


I was just thinking.
If there is a known issue with the onliner xml (at from certain length), isn't it just possible that toad automatically turns off the syntax highlight by default only for that specific clob..?


Turns out that it's not actually the syntax highlighting, it's the bracket matching that's causing the problems. There is some room for optimization in that code, and it can be run in a thread too.

Also, I'm not sure that "certain length" is going to be the same for everyone.

1 Like

Ok, let's hope for the best possible optimization..


We'll get it solved one way or another.

1 Like

How did it go with that..?

I recently noticed, that when I have huge single row sql query open in Editor window, then this also hangs. (try to modify some word or letter from the long sql query, it takes a lot of time)
So probably the same issue.


There are two tickets in our internal bug tracking system for this. One to not perform a particular type of parsing on XMLTYPE because it doesn't apply (this will cut a lot of the time). The other to perform the work that's left in a thread, so your PC won't hang while it happens.

Neither are done in beta yet but they won't be forgotten. It does seem like the same issue. If you want to email me your long SQL, I can check.

This was a good sample for identifying a few performance issues. Three tickets in all came as a result, but things should be improved in the next beta. With a very large, one line XML document like that there's still a slight delay editing the text due to highlighting, but it's fairly reasonable considering the size of the document and lack of formatting. You should be able to work with your data without much issue now.

...but things should be improved in the next beta.

Does it mean that the next GA release also consists of these fixes..?