Access violations

Hi,

Trying to make the big step from 9.7 to 12. I installed the trial and wanted to test it in a real situation. But without knowing what I’m doing wrong I get frequently an access violation. For the old version I have a oracle 32bits client installed. But I’ve also a 64bits client installed. Do I have a kind of conflict? Is it better to install 32bits of Toad? Is there a checklist with possible causes and/or solutions.

Best Regards,

Guus Goossens.

Morning Guus,

It’s highly unlikely you have a conflict between 32 and 64 bits as 32 bit Toad (Is there such a thing?) will not be able to load or use the 64 bit DLLs etc, while 64 bit Toad will not be able to use the 32 bit DLLs etc. This also applies to Oracle clients, if you have 64 bit Toad it cannot use the 32 bit Oracle client software and vice versa with 32 bit Toad.

It might be helpful to the developers if you posted the details of the access violation, things like what it says, can it be reproduced, what were you doing at the time. There may also be a diagnostics file created - go to Help -> Support Bundle and see if the dump data matches up with your situation.

One thing to beware of, if you have 32 bit Oracle client and 32 bit Toad running on a 64 bit Windows OS, then from Windows 7 onwards, there is a tendency for 32 bit “stuff” to be installed in “c:\program files (x86)\blah”. Oracle does not like running from a folder with either ‘(’ or ‘)’ in its name.

In the support bundle details, scroll down to the section “ORACLE HOMES DATA” and check that all the “ORACLE_HOME” entries are outside this infernal ‘(x86)’ folder. It’s NOT a problem to have “inst_loc” pointing at this faulty folder, yo just need the various ORACLE_HOMEs to be well away from that location.

In fact, if you ever use SQL*Plus and runs scripts from withing the ORACLE_HOME, then also avoid having a space in the path to the ORACLE_HOME as none of your scripts will run very well! (Ask me how I found out!)

Make sure that all your ORACLE_HOMEs are valid and on the PATH. This is also detailed in the support bundle section you are looking at.

HTH

Sigh! For “32 bit Toad (Is there such a thing?)…while 64 bit Toad…” read “32 bit Toad …while 64 bit Toad (Is there such a thing?)…” instead, sorry.

Sigh on this side too.

The old toad version could only work with a 32-bits oracle client.

I’ve checked the settings and no strange things found or a remark in that way.

My colleague noticed that Toad tries to create folder …user_files on several disks, depending on where the sql-script was saved. Is that normal or should toad-option be changed? Could a lack of authorisation cause a access violation and the crash of Toad? If yes how to prevent.

I think I found the reason for the access violation. I’d examined the Toad Options and saw something strange with Files->General in Application data directory. The path was a slash only (/). And my colleague had complained that Toad tried to make directories on several locations. I don’t understand why the slash was used and if it was changed after installation. After a deinstall and new clean install I checked this option and found a normal path-setting.

My conclusion is that probably the access violation is caused by the effort to create a directory or file on a location without proper privileges to do so. At this moment no access violations anymore since more than a week.

Only thing remains, how could this happen with as far as I know no customizing of the options.

The access violation case can be closed

1 Like

Hi Guritijo you wont see this but i have been looking for a week and a half for a solution to this issue and yours did it. thank you!