So, when I edit a package, procedure, etc. in the editor right click =>execute => compile all:
1)only the body shows as compiled (compile option set to compile both spec and body always)
2) The last ddl shows up as current but the modified code does not so when I refresh and open the edits are gone, as if I never made changes?
The only way I seem to be able to get them into the db is to execute the edited script in sqlplus. This is not the way versions 11.5 and prior worked they always did what was requested.
Sorry for taking a day to respond. I missed this yesterday.
I tested this with 14.2. If package spec and body are in the same tab, then right-click -> execute -> 'compile all' is compiling both spec and body for me. If they are on separate tabs, then only the item on the current tab is compiling.
Is that what you are seeing? Are you expecting the other tabs to compile or just the objects in the current tab?
I have toad set to open both spec and body as one always. As such I have one file I work with and when done I save it locally, right-click -> execute -> 'compile all' . I do not ever split spec and body into different tabs.
So for you it is working as one would expect...
Then there is something else involved?
I am not using team coding.
I will experiment to see if it is a constant or if there is another factor. In my initial tests it happened in 2 out of 2 package scripts. I even repeated it a couple times in disbelief before posting. I will check into this further but need to get through something else first. Stay tuned please and I'll see if I can provide more details
So in further testing it appears it may have something to do with memory, or the lack of it. Large procedures and packages seem to have the most difficulty.
Yesterday I noticed that when I ran a create synonym statement it finished and showed the timestamp, but did not actually change the synonym, nor did it say synonym created or error.
I believe these are related somehow. I believe there might be something happening regarding memory, even though I have what seems like enough to run TOAD.
That's the hard part, it never presented itself as something tangeable I was able to isolate, and I encountered it in earlier versions too btw. I took a new dedicated interest recently because 11.0 is becoming impossible for me to use with a 19c database LOL.
I used 11.0 next to 14.2 and compared and flipped options, saved, tested, flipped back, saved, tested for quite a while to see if anything had any effect. Why it started working is beyond me, and I have experience as software architect so I'm accustomed to trying a lot of things when seeming random idiosyncrasies present themselves.
I just tested again on 14.2 and its still working fine. At least as far as I can tell...
When you mentioned a memory problem that's all I needed to hear and I switched immediately.
This propels me in to BETA testing now LOL, haven't done this in a while either LOL.
Those memory problems that I was talking about can appear sporadically in 64 bit Toad (and they don't happen in 32 bit). We had 2 support cases recently where they started happening consistently after windows updates.
If it comes back, give 32 bit Toad a try and see if it happens there too. Note, you'll need to install a 32 bit Oracle client for it.
Yeah, memory problems are extremely elusive. When addressing business users I try to use the analogy of an invisible gremlin inside the system running around and sitting in places he ought not be, disrupting things, then later moving to a new location because he gets restless. I've had the misfortune of encountering a couple Oracle Gremlins using RAC, and then Exadata and RAC that kept me up at night.