Post #188,296
12/27/04 2:04:44 PM
|
Access: Runtime error 91.
I keep getting this one: "Run-time error 91: Object variable or With block variable not set".
I'm not sure why. It crops up when there is another error message (ANY error message). I'm using object variables to keep track of certain aspects of the current records, so I'm assuming that any error message sets all object variables to Empty? I am unsure as to how to trap these into not doing this.
|
Post #188,299
12/27/04 2:17:51 PM
|
I think that one means...
..."Go and get a proper database!"
GD&R
Peter
[link|http://www.ubuntulinux.org|Ubuntu Linux]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home]
Use P2P for legitimate purposes!
|
Post #188,303
12/27/04 2:25:41 PM
|
Re: I think that one means...
The problem is, I have historically neglected to pay much attention to proper error handling.
|
Post #188,307
12/27/04 2:42:20 PM
|
From the 10 Commandments of C Programming:
#6: If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest ``it cannot happen to me'', the gods shall surely punish thee for thy arrogance. And yes, it applies to VB as well. :) "Here at Ortillery Command we have at our disposal hundred megawatt laser beams, mach 20 titanium rods and guided thermonuclear bombs. Some people say we think that we're God. We're not God. We just borrowed his 'SMITE' button for our fire control system."
|
Post #188,313
12/27/04 4:08:09 PM
|
So.
How does one go about making a global error handler?
|
Post #188,320
12/27/04 4:37:03 PM
|
In VB?
On Error Resume Next was the most popular method I saw. I wouldn't recomend it myself.
Jay
|
Post #188,332
12/27/04 5:30:43 PM
|
Re: In VB?
Yes.
|
Post #188,347
12/27/04 6:29:15 PM
|
You can use On Error GoTo
Or at least you could way back in the day.
I don't know whether Microsoft has now added some form of exception handling to the language. If they did, then use that instead. (Unless it is really, really broken.)
Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #188,501
12/29/04 3:37:21 PM
|
That's still the way
It's the way Microsoft still does it with the auto code in Office 2003
Private Sub Button_Click
On Error Goto err_Button_Click
code
...
exit_Button_Click:
Exit Sub
err_Button_Click:
Msgbox Err.Description
Resume exit_Button_Click
End Sub
after the err_whatever: tag, you can set up code to compare the Err.Code and handle whatever errors you expect.
~~~)-Steven----
"I want you to remember that no bastard ever won a war by dying for his country.
He won it by making the other poor dumb bastard die for his country..."
General George S. Patton
|
Post #188,350
12/27/04 7:33:54 PM
|
That was a joke
That was a joke, not a programming idea. On Error Resume Next tells VB to simply continue with the next step when there is an error. This causes all sorts of havok when there is a real problem.
But if you want a really global error trap, then either put the entire program inside a try/catch block or a global On Error statement at the start.
There isn't much you can do in VB if you catch errors at that level though. All you can do is present some formatted error information and quit.
Jay
|
Post #188,373
12/28/04 5:30:48 AM
|
For certain techniques, it works.
Specifically, the practice of manually checking ErrCode after steps that could catastrophically fail. It's a bit lazy, though for some types of code, the risk of an uncaught error is suitably low.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #188,567
12/30/04 12:26:38 PM
|
Opinions vary on "Global" error checking in VB.
But in general, it is thought to be a bad idea. I'm in that camp.
bcnu,
Mikem
Eine Leute. Eine Welt. Ein F\ufffdhrer.
(Just trying to be accepted in the New America)
|
Post #188,360
12/27/04 11:24:31 PM
|
That's the technical term "set"
Most likely, you have a bare assignment like
Object = New Thing
...that should be using the Set command instead:
Set Object = New Thing
|
Post #188,421
12/28/04 5:28:42 PM
|
Re: That's the technical term "set"
I am, in fact, using Set: Set cls_BatchALSAdd = New clsBatch I am believing more that I need to trap all my own errors to avoid having Access void the objects when it generates an error. I do not want to do this by putting an On Error Goto Errhandler in each and every procedure though. Can't figure out where to put it though. I can't put it outside of a procedure, but otherwise I (think I) have to put it in every procedure.
|
Post #188,452
12/29/04 2:26:17 AM
|
Yes, unfortunately.
Which is why trapping sucks as a debug technique in VB/VBA. Liberal use of debugger breakpoints will point out the offending code quicker. Which still isn't fun. :(
|
Post #188,468
12/29/04 9:38:14 AM
|
Putting it in every procedure is good practice for VB.
Even if it's just to write to an error log and continue. I've been coding VB for more years than I care to admit (Versions 3-6, am doing a lot less now), but I always made every "Sub" routine a Function that I could and returned a boolean. Each Sub and Function had its own error trap. Sucks, but there you are.
bcnu,
Mikem
Eine Leute. Eine Welt. Ein F\ufffdhrer.
(Just trying to be accepted in the New America)
|
Post #188,479
12/29/04 12:23:59 PM
|
Dangitall.
Oh well, I guess I shall start putting them in. . . .*sigh*
|
Post #188,485
12/29/04 12:45:12 PM
12/29/04 12:57:53 PM
|
Update: (+edit)
I must amend my previous musings on what is happening. It appears as though a recordset reference is being lost somewhere when an error message is generated. I declare said recordset thusly outside of any procedures: Dim rst As DAO.Recordset In the Form_Load Sub I set it: Set rst = CurrentDb.OpenRecordset("tblALS_Add", dbOpenDynaset) This is referencing a different table from the one in current use by the form (I'm doing on-the-fly data entry verification). tblALS_Verify is the current table being used by the form, tblALS_Add is the outside one it is checking against). After any old error message, this bit causes the problem: rst.FindFirst strCriteria It can't, apparently, find any reference to rst anymore. So I assume when a runtime error occurs, those references get dropped. Is there a different way of declaring these or Setting them so this won't occur? [Edit] Yes, I know DAO is old. It's partially legacy code.
Edited by acagle
Dec. 29, 2004, 12:57:53 PM EST
|
Post #188,500
12/29/04 3:27:59 PM
|
You're probably all over this, but...
have you verified that the reference is turned on for 'Microsoft DAO 3.6 Object Library' that it's higher priority than ActiveX Data Objects (I usually turn the latter off altogether)?
Personally, I define my recordset objects within my procedures, and if it's needed in another procedure I'll pass the reference in my parameters. Just remember to 'SET rst = Nothing' at the end of the defining procedure to clear the reference.
And yes I still use DAO regularly myself. I'm just more accustomed to it.
~~~)-Steven----
"I want you to remember that no bastard ever won a war by dying for his country.
He won it by making the other poor dumb bastard die for his country..."
General George S. Patton
|
Post #188,503
12/29/04 3:47:06 PM
|
Re: You're probably all over this, but...
Yeah, I figured that 3.6 stuff out a while ago. I also discovered the original app I borrowed the code from almost does the same thing, but there are pseudo-error traps that keep it from erroring out. But the basic behavior is the same (it pops up the hard-coded error message a couple times before letting you kill it).
So anyway. . . . .the options aren't looking too good unless there's some way to get Access to stop dropping the reference on an error message.
|
Post #188,570
12/30/04 12:39:09 PM
12/30/04 12:40:15 PM
|
Where is the declaration exactly? And a few more q's.
1) I assume the declaration is in a bas module (not Form module), yes?
2) Is the same rst object used to hold different recordsets across multiple forms?
3) Could you post the Form_Load and Form_Activate code?
4) If you write an error handler in the form_load that looks something like this, what is written to your c:\\myerrors.log file?
Form_Load()
On error goto Load_Err
...
Load_Exit:
Exit Sub
Load_Err:
' I don't remember if DAO has an errors collection or not, but I think it does.
' If it doesn't, strike out the errX stuff below
Dim hFile as long
Dim errX as Error
hFile = Freefile()
Open "C:\\MyErrors.log" for Append as #hFile
Print #hFile, Err.Description
For Each errX in DAO.Errors
Print #hFile, errX.Description
Next errX
close #hFile
Resume Load_Exit
bcnu,
Mikem
Eine Leute. Eine Welt. Ein F\ufffdhrer.
(Just trying to be accepted in the New America)
Edited by mmoffitt
Dec. 30, 2004, 12:40:15 PM EST
|
Post #188,910
1/3/05 8:33:37 PM
|
Did you get this fixed?
bcnu,
Mikem
Eine Leute. Eine Welt. Ein F\ufffdhrer.
(Just trying to be accepted in the New America)
|
Post #191,417
1/24/05 5:36:50 PM
|
Re: Did you get this fixed?
Oops, forgot to get back. (I've been having employment issues)
I mostly solved it, but by punting. I've just gone after each individual instance that's causing an error message and dealing with it that way. So instead of going through and putting an error handler in every.single.Sub. I am just dealing with individual errors when they come up and making sure it doesn't error out to a run-time error message.
I need to fix this in future projects though. . . . .
|
