I recently upgraded to Toad 12.6.0.53 base edition. Also recently, our company saw fit to downgrade our windows accounts on our own machines from local administrators to standard users. Coinciding with one or perhaps both of these occurrences has been a sharp increase in the number of access violations in Toad. Usually they aren’t showstoppers, but they are nevertheless disruptive. Anyone else encountering this? Any suggestions for how to end, or at least minimize, the disruptions?
If you can give us some specific details about what you are doing when these AVs occur so that we can reproduce them, we will do our best to get them fixed and if possible suggest a workaround for you. We can’t be very helpful without specific details of the problem.
It’s going to be hard to give better examples, but I’ll try. I’ve had a long relationship with Toad and AVs have always been common, across multiple versions of Windows, across multiple versions of Oracle, across several different machines, usually when I’m running out of free memory. But lately that frequency has spiked. It’s usually happening when I’m running queries; it doesn’t matter whether they’re simple or complex. It also happens when Toad runs its own queries, for instance when refreshing a data grid.
This is why I was hoping that mentioning the bit about how our user accounts were all downgraded from local admins to standard users might ring a bell for someone. I was an admin; I installed Toad myself. I upgraded Toad myself. Toad worked more or less as it always did. Then two things happened more or less simultaneously: my user account was downgraded to Standard and shortly thereafter the latest upgrade was released. I was granted admin rights to perform the upgrade, which I did. Then the rights were re-revoked. And now I get boku AVs.
I wll start capturing SQL and screen shots, and anything else you suggest that would be helpful within the context of our security policies here. I suspect they will be hard to put in context without a database to go with them, but I’m willing to help you help me.
If you ever get an error dialog with a link on it that says “click here”, then do it. That will open up another dialog with a call stack, which is very helpful for us in diagnosing problems. There is a checkbox on those error dialogs to copy it to the clipboard. Then you can post the call stack here and that should help us determine what’s going on.
I want to update this thread with some additional observations. The above error message has no “Click here” button and the addresses are not fixed. But I get this frequently when I have multiple queries on a single editor tab, I put the cursor in one of them, and I execute it by hitting CTL-ENTER. Clicking the Run key doesn’t cause the problem.
This is not a catastrophic error. It usually returns results and I just have to click OK to clear the window. It’s not even a modal dialog, as I can leave it on the screen and continue, and it will just keep opening these windows. While this error is repeatable, it is not consistent. I usually have to get a syntax error first, and even then, it’s not absolutely guaranteed to happen. It also has little to do with the schema, as I can get it to happen with the following editor tab content:
SELECT ‘X’ FROM dual;
SELECT SYSDATE FROM dual;
SELECT 'Date is: ’ || TO_CHAR(SYSDATE) AS date_col FROM dual;
To “prime the pump”, I put the cursor at the beginning of FROM in the last query and hit ENTER twice, putting a blank line between it and the SELECT clause:
SELECT 'Date is: ’ || TO_CHAR(SYSDATE) AS date_col
FROM dual;
Then I hit CTL-ENTER. This gives the following dialog:
(Incidentally, if I click the Run button on this query, which is perfectly formed despite the blank line, I don’t get the above message. Why is that?)
Now I remove the blank line:
SELECT 'Date is: ’ || TO_CHAR(SYSDATE) AS date_col
FROM dual;
I hit CTL-ENTER, and–although not guaranteed–I get an access violation:
This is not a showstopper, and I’ve always gotten perplexing and inconsistent AVs in Toad over the years. This one just seems to be more consistent than any others I’ve ever seen and it seems to have started happening much more frequently with version 12.6.0.53. Hopefully I have given enough info to point to a cause, or at least narrow the possibilities.
Just to remove confusion…in my post above, I definitely put an additional blank line in the first example:
SELECT 'Date is: ’ || TO_CHAR(SYSDATE) AS date_col
[a blank line was here]
FROM dual;
and took it out of the second example:
SELECT 'Date is: ’ || TO_CHAR(SYSDATE) AS date_col
FROM dual;
But they both look the same when I posted it. There must be a formatting rule that removed the extra blank line.
Sorry for spamming my own post…it doea appear now that the first address in the AV is consistent:
I’m not sure about the Access Violation, but there is an important difference between CTRL+Enter and the Run button (or F9).
F9 will parse your query using the semicolon as the delimiter between statements, so it can read through a blank line to the true end of statement.
CTRL+Enter will treat a blank line as a statement delimiter and only execute the text between the blank lines. CTRL+Enter can be useful if your query has subqueries and you want to execute a subquery by itself (just put blank lines around it and CTRL+ENTER). Otherwise, you are better off using F9.