Losing global variable in a report

[Stoss]

I have a access 2003 database. I have set up a global variable in Module1. The reason I set it was to indicate what location the access database is using. I have 3 access databases that are using the same DB structure. Oh, I used a global variable because different areas of the DB runs the reports in a different way (sometimes Outputto, sometimes Openform from another form).

Here is how I set it up in Module1
Global strLocation As String

Here is the weird part, I set strLocation = "PKS" in the form load event of the default form that loads. When I have the automated reports launch, I concatenate strLocation & strFilename (which looks like this... PKS - Monthly Reports.rtf). It works sometimes but other times I see the reports come across like ( - Monthly Reports.rtf). In other words, it seems to lose the global variable and other times it seems to use it just fine.

Any ideas would be greatly appreciated as this is driving me mad!
-Stoss

 

[Galaxiom]

Global variables are reset when code is stopped.

 

[smig]

you can save it to the registery
look for SaveSetting() and GetSetting()

 

[DCrake]

Are you opening the report from the form that sets the global variable?

strLocation = "ABC"
DoCmd.OpenReport ....

I use them all the time and I have heard of them being lost but thankfully it has never happened to me.

 

[Stoss]

I set the var strLocation = "ABC" in the Form_Load event on the default form that opens. I declare the Global variable in Module1. This variable is used from another form "frmReports" using an docmd.OpenReport call or it is also used automatically using code in Module1 in an docmd.Outputto call. So two different places may use this Global variable. Hope that makes sense.

I am just wondering what is SOMETIMES killing that global variable? Am I declaring it right? Did I put all the code in the correct events? etc.?

Thanks,
Stoss

 

[ChrisO]

>>I am just wondering what is SOMETIMES killing that global variable?<<

Four possible answers as far as I can see: -

1. At the time the variable ‘is missing’ it has not been initialized.

2. You have had an unhandled error and you allowed the project to do a reset.
If that were true then I guess you would have mentioned it, so let’s rule that out.

3. You have code somewhere that is clearing the variable but you can’t find it.

4. You have two, or more, variables that are called strLocation but they have different scope.

Chris.

 

[vbaInet]

I was just about to post before you posted Chris

I was also thinking about the possibility of 2 through 4.

Just for the sake of clarity, could you try setting and getting the value of the variable via a function. What happens?

 

[Stoss]

Points replies...

1. I believe it is being initialized because sometimes it works. So I think this can be ruled out.

2. Unhandled error....I am not detecting anything but maybe I put "on error resume next" somewhere and there really is an error that I am not seeing.

3. I did a search and nothing is overriding that variable, it is just being used in several places. Also, this is being used on different reports as a Activate Event just to populate some text boxes on those reports.

4. Only 1 strLocation is set and nothing overriding it.

Thanks for the help, maybe something there will shed some light.
-Stoss

 

[Stoss]

vbaInet, this brings up a good question at this time.

As posted earlier, I declare it Global strLocation as String in module1. I set it strLocation = "ABC". Is this correct or do I have to do something more "fancy" like -- Set strLocation = "ABC"? I am not that familiar with Set and Get and any of that stuff so I don't know if it applies here and if it would even make a difference.

=Stoss

 

[vbaInet]

3. I did a search and nothing is overriding that variable, it is just being used in several places. Also, this is being used on different reports as a Activate Event just to populate some text boxes on those reports.

Move the code to the Load event and see if that makes a difference.

I would advise you set a Watch to test for when the value is changed.

 

[vbaInet]

vbaInet, this brings up a good question at this time.

As posted earlier, I declare it Global strLocation as String in module1. I set it strLocation = "ABC". Is this correct or do I have to do something more "fancy" like -- Set strLocation = "ABC"? I am not that familiar with Set and Get and any of that stuff so I don't know if it applies here and if it would even make a difference.

=Stoss

Nothing wrong with the way you're setting and or getting the variables. What I mean by a function to set it is:

Public Function SetMyVar(strVar as String)
     strLocation = strVar
End Function

To get the value of the variable:

Public Function GetMyVar()
      GetMyVar = strLocation
End Function

Then declare your variable as Private. That is, change Global to Private or Dim.

 

[Stoss]

Thanks, great minds think alike (probably should have thought about it sooner though) I was just about to do that.

Here is a question I just thought about. I am running the code in module1 for the automated reports which launches on the Form_Close event (i.e. when exiting the DB). Do to some weird thing, could strLocation clearing it self on close before the code runs. I mean, technically, the code should always run first before clearing it out. I would think because if not, it would never run properly.

-Stoss

 

[vbaInet]

Nope, a variable cannot on its own re-initialise itself. Chris has given you the possible scenarios where the variable might be reset.

By setting a watch and running the code you will be able to see what's causing the problem.

However, I feel you don't need the variable. Just use OpenArgs which is one of the parameters in the OpenReport method.

 

[Stoss]

I need the variable because I don't just use Open Form, I also use it in Outputto and with Outputto you can't pass openargs parameters.

I have a watch on it now and I am doing everything I can to break it but it is holding steady.....err...just when you want something to break it won't.

-Stoss

 

[ChrisO]

Here’s how to cause the scoping error I was talking about.

A2003 attachment.

Open Form1 and close it.

 

[Stoss]

Thanks Chris, I checked it out and that makes sense but I don't think I am having that issue because I can click on anything it the value stays.

At this point, I put a watch on strLocation and it never changed (i.e. went blank). So, my thoughts at this point are it is causing some kind of issue "sometimes" with the close event. I am not sure how to test that since it is on the close event and will kill my watch...

-Stoss

 

[Stoss]

Err, I apologize, I made a mistake in my wording earlier. I put the call to the function I made in the Unload Event not the close event. Still doesn't make sense but I thought I should clarify. According to access, the order of events should be Unload - deactivate - close.

-Stoss

 

[The_Doc_Man]

In the past, I have had globals go away on me. Invariably, it was due to an error trap occurred that crossed a scope boundary.

For example, I have a routine in a class module on my form. It sets a global variable. Somewhere inside the routine it calls a function in a general module. The function fails, but because it doesn't have its own trap code, the trap handler has to look for a higher-level trap handler (i.e. in the caller of the general module.) That is a trap across a change in scope, and that is when I lost the globals.

It is very hard to bullet-proof your code, but judicious use of NZ() and a few other tests can go a long way to reducing the number of such events.

What it means in practical terms is that anything in a general module that could be called from a class module might benefit from having local trap handlers so that scoping boundaries aren't crossed. I've done that where I could. I've still got a few cases of that, but I'm slowly reducing their frequency.

Now, as to WHY this might happen? Even global variables go on the stack unless you take pains to specially declare variables of a more permanent nature. If something happens to trash the stack because of that trap, you've lost the memory in which those variables were declared.

This next part is conjecture, but it might make some sense. When Windows NT was written, Dave Cutler was the primary architect. He was also the primary architect of the OpenVMS operating system. In OpenVMS, you have call frames just like the ones you have in Windows. (When debugging, it is the call frames that allow you to see the call stack window.) When you declare a trap in a routine, it is local to that routine because the frame has a trap handler address.

If the trap occurs when there is no handler, the current subroutine is deinstantiated but information is passed "up the stack" as the stack gets "unwound" (i.e. cleaned) while looking for a declared handler. The trap gets passed up until it reaches the base context. For OpenVMS, this is called DCL (when it is an interactive session) and the handler is called the "Last Chance" handler.

For VBA, it might well be the VBA "environment" code. Which means if you make it all the way back to the kernel of VBA, you unwound ALL definitions, even those associated with general modules. Remember, those don't get instantiated until you call something from within them, either.

It's the closest I can come to explaining it in terms that I know about.

 

[Stoss]

Thanks for the explanation Doc Man! I get the feeling you know way too much!!!

Is there any downside to putting the strLocation = "ABC" in the Lost Focus event of my main form (i.e. form that is alway open)? So, it would update more often and even if it loses it, it might get it back?

-Stoss

 

[Stoss]

Thanks for all your guys/gals input!!!!

I think that I narrowed it down but I am not quite there. I figured out that when exiting the DB, if I exit with the "X" or go to file -- exit, code work perfectly. It add in the strLocation just fine. However, if I click on a self made Exit Button, then it seems to lose the strLocation info. Does that help narrow it down and what should be my next step? Again, I know some of you have spent some time with me on this and I really appreciate it.

-Stoss