For some reason, this one problem report I keep trying to send to the group via e-mail isn’t making it there. So I’m posting from ToadWorld and hoping the others just die out is cyberspace without spamming the group when it finally hit the boards. 
First the great news. I’ve been working in the Editor all day (it has now been all day yesterday and all day today with 2 times I had my computer hibernate in between) and it hasn’t crashed at all!!! This is a ginormous improvement over the past few weeks, so, Michael, a million thanks for the fix.
I’m working on a package in the editor that has some complicated dynamic sql building in it. So I’m making a few changes, formatting, compiling, swapping tabs to execute the code, refreshing a Desc window grid that has the SQL I’m building stored in the table, and then switching back to my package to tweak it again and repeat.
As I’ve been working, I’ve found that after several sets of changes to my package, I’ll all of a sudden get a compile error
[Error] PLS-00103 (733: 33): PLS-00103: Encountered the symbol “end-of-file” when expecting one of the following: ( begin case declare end exception exit for goto if loop mod null pragma raise return select update while…
Formatting shows no syntax errors, but the compile fails. If I then save my package file, close it, open it in another tab and compile again, the compile works just fine. So it appears that the problem is in TOAD, not in my code.
I’m not sure if this is sufficient information to give you - let me know what other details you need.
Blessings,
Phyllis
Hmmm. My reply won't post by email either.
hasn't crashed at all
Awesome!
Formatting shows no syntax errors, but the compile fails
It sounds like the parser data Toad has maintained is out of sync with your code and it's sending incomplete source. I'll take a look tomorrow for obvious issues, but if it happens again try this to confirm. Click the little, blue refresh circle on the navigator panel. This will dump all stored parser data and fully parse. If compiling still fails then it's something else.
Thanks,
Michael
I have no idea if this is fixed for next beta, but I did find a case where the list of objects maintained by the editor was out of order. This is fixed for next beta and may (or may not) have caused what you’re seeing.
Thanks Michael. I'll let you know if I see this any more.
On Fri, Apr 3, 2015 at 11:53 AM, Michael Staszewski bounce-mstaszew@toadworld.com wrote:
RE: Editor - Compile Error when no error exists
Reply by Michael Staszewski
I have no idea if this is fixed for next beta, but I did find a case where the list of objects maintained by the editor was out of order. This is fixed for next beta and may (or may not) have caused what you're seeing.
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 
407-515-4452
phyllis.helton@cru.org
Compiler errors happen! The following approach should help you get through them with a minimum of fuss and frustration when they do occur.
Avoid them! How? By knowing what you are doing before you do it. Take good notes, keep your source organized so you can find it and refer to it to see how you did something successfully before. Make a cheat sheet of things you do often but can't quite remember yet.
Don't write very much code! Well, not all at once anyway. Develop incrementally. Write a little, compile, test (if appropriate), repeat until done. By writing a small amount of code at a time you know any compiler errors you encounter were introduced recently - if you didn't write very much you'll have a better idea where to focus your attention.
ALWAYS ALWAYS ALWAYS fix the first compiler error first (by this I mean the one the compiler spit out first). The first error is almost always a real error. Subsequent errors can simply be the result of the compiler being confused by the first error. It makes an attempt to tell you everything that is wrong but it is not very good at it. As you become more experienced with compiler errors you can dive down the list, ignoring the appropriate ones, and fixing the valid ones. Until then, and especially when you feel dazed, confused, angry, frustrated (fill in your favorite compiler-error emotion here), et cetera, you should fix the first error first, if the second error makes little or no sense, just compile and fix the new first compiler error, if any, repeat until done.
If you can't figure the error out, try commenting out the code you have most recently written until it goes away. Then, reintroduce the commented out code, a bit at a time, until the error reappears. Make sure you understand what specific code caused the error and commit it to memory so that you can avoid that error in the future. This is called learning from experience - very important to a programmer's sanity and success! Maybe everyone's sanity and success for that matter.
Take regular breaks. Especially when you are feeling stuck and frustrated. You'll be amazed how much more fun programming can be if you approach it as an interesting challenge when you are feeling fresh. I, and many others I know, have solved many-a-problem by simple moving away from the computer. Some unconscious part of your mind continues to puzzle over the problem and often solves it for you with little or no apparent effort at all.
Regards,
Rachel Gomez
