How to solve a "Return without GoSub" Issue

Question

_{Wednesday, June 1, 2011 7:31 PM}

On a form that worked for weeks, I'm getting a "Return without GoSub" error.  It makes no sense whats so ever. The code it is happening on is extremely simple:

   Label35.Visible = False

That's it.

I recently had this happen to another form and solved it by simply copying the form's controls to a new form.  It happens I believe only after compacting. 

The database must be currupted somehow.  Does that sound true?

If so, what should I do to fix it?  Please be specific as I'm not good with the technical stuff.

Thanks,

Matt

All replies (14)

_{Friday, June 3, 2011 8:13 PM ✅Answered}

>    An Error occured while loading 'Job01ResultsforStersub'.  Do you want to continue loading the project? <

That was problably causing the error you had, and you have got solved now.

Dont forget after done with coding to Compile your database again, see if there are any errors raised.

Goto Visual Basic screen, Menu Debug, Compile ... [your databasename].

> By the way, when I open a module for code, all the modules open up behind it.  I believe there is a way to have only the single module open, right?  How is that done? <

What do you mean like Cascade? All modules (code) are opened when going to your Visual Basic screen.

You might press Restore or open one of the Modules Maximized.

HTH,

Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"

_{Wednesday, June 1, 2011 9:35 PM}

Can you post the complete code?

_{Wednesday, June 1, 2011 11:45 PM}

I don't think the code is the issue.  The code is on the Mouse Move of a label and reads, in full:

    Label35.Visible = False

That is it.  This worked for two weeks and now fails for no reason.  Another form had an unbound Combo named "BatchNumberChosen".  I have a query that filters to it with:

     Like (IIf(IsNull([Forms]![StericycleHistoryfrm]![BatchNumberChosen]),"*",[Forms]![StericycleHistoryfrm]![BatchNumberChosen]))

I've been using that filter format for over 10 years.  This one worked for 4 days or so.  Then I compacted and then it didn't work.  No reason.  I changed the name of the filter control to BatchNumberChosen1, and changed the query filter and it worked again.  Then I compacted.  Then it broke again.  So I then moved all controls to a new form and it worked again.  It even worked after compacting.

So forms are getting weird for no reason, or usual reason.  There is something messy, corrupted about it, I believe.  Doesn't this all sound as if something is funny beyond the code?  Is the Return without GoSub a usual error when a database gets corrupted?  I don't know.

I just heard something else is now failing that has worked for 8 months!

Thanks,

Matt

_{Thursday, June 2, 2011 7:03 AM}

If C&R did not work, however you did not indicate the version of Access and what service pack was installed.

It could be that your Access installation is corrupted, maybe a re-install with service pack might solve the problem.

_{Thursday, June 2, 2011 3:18 PM}

Hi Matt,

You might try to Decompile your Access Database and see if that works for you:

http://access.mvps.org/access/bugs/bugs0008.htm

And try to create known names for you Label, while Label35 doesnt ring a bell after several years later...

HTH,

Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"

_{Friday, June 3, 2011 1:31 PM}

The database has yet another error.  In a module that has been working for months, it says it is misnamed or something--I forgot the actual message--and won't let me in at all.  I had to copy the same module into it from an old version and rename it for the functions within it to work.  Now it works very well.

So does all these issues sound as if I need to decompile?

The above link about decompiling is too old.  I have Access 2007.  What are the steps to take?  I'll google in the meantime but I would like some more input about this.  I'm very nervous.

Matt

PS:  By the way, the label on mouse move issue above was just a silly bit of code in the start up form just for fun.  I put 40 or so labels on the page with the same word in eachvery faintly seen and stylish, you see.  When you move your mouse over them, which you will likely do to open some forms, they disappear.  But some, after disappearing, will become visible again too.  The trick is to get them all to disappear.  It is seemingly impossible, but possible owing to one hidden label placed in a secret location.  So I didn't bother naming the labels.  It's not the fact that I can easily fix this issue but that issues are popping up on important things as well now and then.     

_{Friday, June 3, 2011 1:50 PM}

You dont have to be nervous.

The above link might be old, but it works the same for your Access 2007 database, see also below thread for the steps to take:

http://rogersaccessblog.blogspot.com/2009/04/how-do-i-decompile-database.html

After the Decompile you can Compile your code again.

Furthermore when developing your database, make sure you frequent back-up your database, just in case something goes wrong or corrupted.

HTH,

Daniel van den Berg | Washington, USA | "Anticipate the difficult by managing the easy"

_{Friday, June 3, 2011 4:03 PM}

I decompiled it.  I used these directions:

http://www.fmsinc.com/microsoftaccess/errors/Bad_DLL_Calling_Convention.asp

(Another version of this same page has the quotation marks around the "C:\Program....MSACCESS.EXE" part.  It took me a long time to figure out to do that.)

I got a strange error after choosing the database to decompile:

   An Error occured while loading 'Job01ResultsforStersub'.  Do you want to continue loading the project?

Saying yes only caused a bunch of issues.  So I deleted the sub form and the control to it on the main form.  I accepted the fact that I would have to rebuild it.

After that, it opened without error and I decompiled.  I then rebuilt the missing form, etc. and tested the oddities.  They worked, especially my silly Start Up Form puzzle.

So I think it is okay.  But I don't know for sure yet.  Will test.  It's in the development stage still and I keep old versions daily.

By the way, when I open a module for code, all the modules open up behind it.  I believe there is a way to have only the single module open, right?  How is that done?

Thanks,

Matt

_{Thursday, March 16, 2017 3:23 PM | 1 vote}

Ok here is the deal:

I was working on a prior made ACCESS DB project, let’s call it DBA and was using all the forms, reports and many tables already made to make the new DBB. Since this was another project I call it DBB but left most of the Expressions, Macros and Codes without changing name. Everything was going perfect until . . . I tried to run the macros again on my new project; so opening the DBB and going right to work was giving me the same warning RETURN WITHOUT GoSub, as soon as I was getting into the Visual Basic area, without edit or doing anything and returning to work was enough to fix the error problem.

So I was getting frustrated until I read this article and fix it once and for all:

Go to the Data Base Tools area open the Visual Basic editor go to edit project properties and just update the project name from DBA to DBB. Save your changes and exit everything. Next time you open your project all your MACROS, EXPRESIONS AND CODES will be running smooooooth. 

_{Tuesday, November 21, 2017 1:44 PM}

Now THAT did help. Thank you!

_{Thursday, December 6, 2018 11:42 AM | 1 vote}

I have had the problem you describe, many many times. Events associated with form controls that have worked absolutely fine previously suddenly stop working and display "Return without Gosub" errors. I concluded that the database has become corrupted in some way. The method I have used to get around this issue that has consistently worked for me is as follows:

1. Create a new blank database

2. Import All objects from the misbehaving database including all code modules

3. Open the new database, goto "file > options > current database" and set all options for the database to match the misbehaving database. 

4. Close and rename the misbehaving database (I usually put a z before the filename) so it is not permanently lost.

5. Close and rename the newly created database to the same name as the database that was previously misbehaving.

I have been developing Access databases from Access 97 through to Access 2013 and have had to do this scores of times. It has always solved this issue.

_{Tuesday, January 8, 2019 3:15 AM}

While obviously there can be genuine cases of "Return without GoSub", I think many of the cases here are Access being flaky. Two months ago I wrote a new auto-launch form to do a bunch of stuff on startup. It worked beautifully for two months.

Back from the new year break, and nobody's touched the database but me, starting the database gave a "Return without GoSub" error for the auto-load form OnLoad event. It also gave the "Return without GoSub" error for one of the number of buttons on the form, but none of the others.

The number of "Return" statements in my whole project? Zero. So, quite perplexed as to how a "Return without GoSub" error could occur.

A Compact and Repair did not fix the problem.

So, I commented out every line of code in the form's OnLoad event, and the OnClick event of the 'faulty' button, and tried uncommenting lines to see where the problem was.

For both the form and the button on it, uncommenting lines back to the original, the error no longer occurred and all behavior is exactly as it should be.

Reviewing the situation, I find that the two items reporting the error were the only VBA associated with the form. All the other buttons etc ran Macros rather than VBA. Seems like a compile error in VBA, with a recompile forced by commenting and uncommenting the code.

_{Wednesday, January 9, 2019 7:52 AM}

Neilsky,

Most or all of us here would not know what's the actual error or mistake you make in your code.

In VBA, it's a good idea to include "Option Explicit" to avoid undeclared variables compile your code once you are done.

Sometimes it's not a good idea to trigger an event procedure inside another event procedure. It might work in one case but not the other.

Bad naming convention happens all the time, it a good idea to review your code thoroughly again.

_{Tuesday, December 3, 2019 4:26 PM}

Worked like a charm. Thanks for the reminder. Our Access database application, after import into a fresh Access shell, found multiple lines of legacy code which needed sun-setting then all errors such as those identified in this pot, disappeared.