TransferText command failing !?!

[Dorian]

I have a TransferText command that just started to fail, it worked fine in
the past and no coding changes have occurred. The odd thing is I have an
error trap and err.description returns a blank and err.number is zero. How do
I debug this? What could cause this to fail. here is the code:
strPath = "C:\Exports\TWS\TWS_"
DoCmd.TransferText acExportFixed, "tblTechAssigned", "tblTechAssigned",
strPath & "tblTechAssigned.txt"
There are a series of such commands above this line (for other tables) and
they all worked fine. Yes the table exists and so does the path.
-- Dorian
"Give someone a fish and they eat for a day; teach someone to fish and they
eat for a lifetime".

 

[Chris O'C via AccessMonster.com]

err.number = 0 means either there's no error or it's been reset.

I know this sounds like a dumb question, but please humor me. What makes you
think the command is failing?

Chris

 

[Dorian]

On error is triggered and goes to my error handler (which then displays
err.description). Its always triggered at the same point exporting this
particular table.
-- Dorian
"Give someone a fish and they eat for a day; teach someone to fish and they
eat for a lifetime".

 

[Chris O'C via AccessMonster.com]

2 ways to enter the error handler:

1 - trigger it (as you said) by encountering an error
2 - entering it because there's no exit function or exit sub before the error
message is displayed.

#2 is most common when err.number = 0 so check your code to make sure that's
not happening.

Next, check if err.number is being reset with err.clear before it reaches
your msgbox or if it's being reset by leaving the proc, running another proc
and coming back to the current proc.

Chris

 

[Dorian]

Hi,
Neither is true, code is not falling through. On error is being triggered,
it is the only way to get to my error handler. There are no err.clear
statements.
As I said this code worked until the beginning of this year, then stopped
working, no code changes have been made.
I just noticed though, in my error handler,I do have an 'On Error Resume
Next' before displaying the error, does that reset the error object?
-- Dorian
"Give someone a fish and they eat for a day; teach someone to fish and they
eat for a lifetime".

 

[Chris O'C via AccessMonster.com]

When you go to the trouble to write an error handler don't use "on error
resume next". "Resume next" hides the error. Drop it.

Yes, it resets the error object. That's part of hiding the error. That's
what you ask it to do with "resume next".

Chris

 

[Dorian]

The intention was not to allow any further errors in the error handler....
but I guess I need another way.
-- Dorian
"Give someone a fish and they eat for a day; teach someone to fish and they
eat for a lifetime".

 

[Chris O'C via AccessMonster.com]

Resume next doesn't prevent errors. If you want to ignore additional errors
you can disable error trapping in the current proc:

on error goto 0

Beware that if your proc hits a fatal error and you don't trap it, it could
close your app. But it usually tells you it bit the dust before it closes.
In that case you know your error handler needs to be more robust.

Chris

 

[Chris O'C via AccessMonster.com]

Make sure your code reads the error before you disable error trapping if you
disable it inside your error handler.

Chris