Toad World® Forums

SQL Recall problem

I’m using the most current beta (.10) in 12.8. Toad doesn’t save the last executed statement into SaveSQL.xml file. The size of file remains the original one (mine is 438 013 byte) , but the last modification always changes to the sysdate. Also an empty record created in View|SQL Recall: the connection string and the time of execution information are correct, but there is no visible statement for it.

My Editor|Code Assist|SQL Recall|Save only valid statements is on. The SELECT statement - which is executed in the Editor - gives a result set, with 2 rows.

In 12.7 there was an option how many statement should save to the SQL Recall file. I don’t know this option was deprecated in 12.8beta, but I didn’t find any option like this one. In Toad.ini SAVE_SQLS=1 and NUM_SQLS=500 are present.


I can’t reproduce this. Can you send me a SQL statement offline that reproduces or are all statements problematic? If all then send me your user files. Thanks.

In 12.7 there was an option…

The option has gone away for now. In the past you could limit total number of statements or total per connection. Now I’m letting them all stay, but if load time of the file exceeds 200 ms a warning message is shown suggesting that you cleanup the history. Performance is going to vary per machine and size of each statement, but for me a 200 ms load time was ~7000 statements and that was the point I could detect slowness in the GUI with bulk operations like select all. It was still usable, but noticeably affected.

Toad has supported importing of SQL recall for several releases now and during import you can append to what you already have or replace what is there. The option was not obeyed during the import, but the list was trimmed on next execution. So statements you explicitly said to import could be nuked with no way for you to get them back without bumping up that option value.

If it is preferred to have the option back instead I’ll make it so.


None of a statement appear in SQL Recall panel. I’ll send my User Files, but it’s online. I gave the address of it earlier.


I think I have the same issue which is why I’m replying to this thread rather than starting a new one - Sql Recall does not seem to be saving statements properly. When I look at the Sql Recall window, it’s great that everything is grouped into dates but most of it is empty! Bearing in mind that I use Toad every weekday and execute many statements each time, my Sql recall seems a bit light! Friday 24th July, 1 statement (blank), 23rd July, 2 statements (both blank), 22nd - 2, 21st - 1, 20th - 1 then it jumps to Thursday16th (3) then Friday 10th (4), 9th (7) then 3rd (7) but then prior to that it looks a bit more normal, 2nd (34), 1st (17).

It used to be (as recently as 12.7) that I could execute a statement and it would immediately appear in my Sql recall but now if I execute a statement, my Sql recall window shows 1 statement for today but it is blank. No matter how many other statements I execute in that connection, I only see 1 blank entry. If I open a new connection, I get a 2nd blank entry!

Likewise. Using… press F8 to open SQL Recall panel… expand the Today node… none of my SQL statements are shown, just a header for each connection.

I didn’t make the cutoff for the next beta, but this will be fixed in In the meantime you can execute with F9 instead of CTRL+Enter as a workaround.



Is it possible you have a filter on the SQL History window?

On Mon, Jul 27, 2015 at 5:59 AM, NoDabble wrote:

RE: SQL Recall problem

Reply by NoDabble
Likewise. Using… press F8 to open SQL Recall panel… expand the Today node… none of my SQL statements are shown, just a header for each connection.

To reply, please reply-all to this email.

Stop receiving emails on this subject.

Or Unsubscribe from Toad for Oracle - Beta notifications altogether.

Toad for Oracle - Beta Discussion Forum

Flag this post as spam/abuse.

Phyllis Helton

Data Magician
Digital Strategies, Cru | Data Sciences & Analytics
Office :phone: 407-515-4452

Just downloaded and it does indeed seem to be fixed. Thanks Michael.