Global variable losing value for no apparent reason

[bcap]

More dickheadery:

DAO is nowhere a decade ago!

 

[Keith Wilby]

More dickheadery:

[Scrubs' Dr Cox]
I ... don't know ... who you are ... but thank you <kisses forehead>
[/Scrubs' Dr Cox]

;-)

 

[BruceM]

If it's useless to you, feel free to go away.

I disagree.

DAO is pointless. Any DAL that makes you clean up your variables-- is
just flat out-- not useful to me.

I disagree.
I find DAO much easier to code and peforms better.
Even after pushing ADO for a few years, Microsoft has given up on it and
gone back to making DAO the default. There has been no work done on ADO
since (I think) 2000.

Access using DAO is a very stable and reliable platform (unlike Aaron).
--
Dave Hargis, Microsoft Access MVP

Weird. [...]

Thanks for all the comments, helpful or not! Yes, ADO is "better"
than DAO, but there's no budget to replace it. Yes, using various
tricks to link the front and back ends is a good idea, but I've
already done that. Sure, hidden fields on hidden forms are a good
wheeze (I've spent the last six years doing this in ASP.NET!) Where
feasible, I've added error handling but, as I said, there's no budget
to make the whole thing watertight.

I now know what the problem is, and it was a sort of error, but a
silent one. The application automates Word but for various reasons,
the reference to Word cannot be static and is set dynamically at start
up and removed during the closing routine:

For Each Ref In References
If Ref.Name = "Word" Then References.Remove Ref
Next Ref

All I had to do was to change the order of the various operations in
AutoExec - specifially, to make sure that the reference was added
BEFORE the assignment of the global variable.

At some point in the future I'll suggest to my client that the code
could do with a serious going-over but, despite them being one of the
most successful companies in the UK, they are unlikely to stump up for
this until they really have to.

Thanks all

Edward

 

[Troll Chaser]

You are incorrect because it involves re-running a lookup every time,
something a global variable is designed to avoid. But then since you have no
idea how to program a database, you don't realize that, do you Troll Boy?

how am I incorrect?

can MS Access _NOT_ store variables in a table?

 

[sgmaxmp11]

"Bob Quintal" <[email protected]> à¢Õ¹à»ç¹¢éͤÇÒÁ
news:[email protected]...

 

[lyle fairfield]

Are you saying that Resume Next results in pointers to Global
Variables being released, ie a Global String Variable length is now
zero?

I've never experienced that.

Here is some code that indicates it is not so.

Global SomeGlobal$
' or Public SomeGlobal

Public Sub SomeTest()

SomeGlobal = "SomeString"
Debug.Print "Before Error SomeGlobal = " & SomeGlobal

On Error Resume Next
Err = 0
Debug.Print 3 / 0
If Err.Number > 0 Then Debug.Print _
Err.Description & vbNewLine & "There was an error!"
On Error GoTo 0

Debug.Print "After Error SomeGlobal = " & SomeGlobal

End Sub

'Before Error SomeGlobal = SomeString
'Division by zero
'There was an error!
'After Error SomeGlobal = SomeString

I seldom use seldom Global Variables, preferring Modularly Scoped
Variables which are referenced by Public Functions, Registry Settings
and CurrentProject Properties. The Public Functions can meet the
"value lost" case by beginning with
If len(SomeGlobal) = 0 Then InitializeSomGlobal
where InitializeSomeGlobal is a procedure that does exactly that.

 

[So Sorry For Poor Aaron]

DAO did not get a major revamp... it is merely a new badge.

ADO has been through many incarnations over the past decade.
DAO wasn't included with Windows or Office for 5 years.

Oh, cry for the poor, poor, pitiful little aaron... who can't even keep
straight that "Windows or Office" is not the same as "the MDAC".

His statement is completely, wholly, and demonstrably wrong. But "wrong" is
aaron at his best or his worst... whichever, he's always so full of fecal
matter that he's near to exploding and contaminating everyone nearby.

 

[The Frog]

I just create a class module, and instantiate it when the application
starts. It has all the code necessary to handle the proper set up of
global vars and I find it keeps things neat and clean. Never had a
problem with it resetting to 'nothing'. If I want to know a value, I
just check the associated property

Cheers

The Frog

 

[Tony Toews [MVP]]

I now know what the problem is, and it was a sort of error, but a
silent one. The application automates Word but for various reasons,
the reference to Word cannot be static and is set dynamically at start
up and removed during the closing routine:

Good trouble shooting.

However I would suggest an alternative approach to the Word reference issue.

Late binding means you can safely remove the reference and only have an error when
the app executes lines of code in question. Rather than erroring out while starting
up the app and not allowing the users in the app at all. Or when hitting a mid, left
or trim function call.

This also is very useful when you don't know version of the external application
will reside on the target system. Or if your organization is in the middle of moving
from one version to another.

For more information including additional text and some detailed links see the "Late
Binding in Microsoft Access" page at http://www.granite.ab.ca/access/latebinding.htm

As far as ADO vs DAO goes they both work just fine in Access and I see absolutely no
reason to convert from one to another.

And please ignore anything Aaron Kempf states. He is rather monomaniacial.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[rkc]

34g2000hsh.googlegroups.com
:


There exists and has to my recollection always existed a bug where
global variables are reset on some or all unhandled errors. I do
remember having a similar problem with an error that was handled by
a resume next, many years ago, (Access '97, maybe even Access 2).
Perhaps that was fixed.

How I wrote code years ago is different than how I code today.
That comes from experience gained on using the tools and features of
the language. I seldom use globals any more and pay more attention
to error handlers.

On Error Resume Next handles errors as long as the code it is in is in
scope
and On Error Goto 0 has not been called.

To extend Lyle's example with a call to another method:

'------
On Error Resume Next
Err = 0
Call CauseError
If Err.Number > 0 Then Debug.Print _
Err.Description & vbNewLine & "There was an error!"
On Error GoTo 0

Debug.Print "After Error SomeGlobal = " & SomeGlobal
'------

Sub CauseError()
Debug.Print 3 / 0
End Sub

The error in CauseError is handled by the calling code.

I would be a very scary thing indeed if On Error Resume Next did not
handle an error and global variables were reset because of it.