Taking care of error 1104: "Error reading file" 1

[mibosoft]

Hi,
If my app has a database open, stored somewhere in a LAN and the connection goes down, I get error 1104 "Error reading file". In my error handler, I would like to take care of this and shutdown nicely without error messages and "file open" dialogs. Any example on how to do this? The app may have dialogs open with code in the unload events that does something with the tables. I have tried different variants of closing the database in the error handler an even re-directing the aliases to dummy tables but nothing works.

BR,
Micael

 

[Mike Lewis]

Micael,

The first thing you need to do is to add an error-handler to your application (if you don't already have one). An error handler is a routine that is called from the ON ERROR command. If you need an example of an error-handler, see the Help topic on ON ERROR.

Within the error handler, use the ERROR() function to look for the specific error you are interest in (1104 in this case). When you detect that error, you can display your friendly message to the user, then take whatever other action you like, such as closing down.

If the user sees a File Open dialogue before the error-handler kicks in, you can avoid that by execting SET TABLEPROMPT OFF at the start of your main program. However that command is only available in the most recent versions of VFP.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[mibosoft]

Hi Mike,
Thanks' for your answer.
Yes, I do have an error handler that catches 1104 but the problem is what actions to take when access to the database/tables is lost. The behaviour seems somewhat un-controlled. Issuing "close database all" or "clear windows all" isn't enough. Sure this problem must have been taking care of by lots of programmers in lots of applications. I'm looking for code examples.

 

[Mike Lewis]

Micael,

I suggest that the problem isn't a programming one. It's more a matter of your deciding what action makes sense in the context of your application.

If you lose access to the database, and assuming there is no chance of regaining access and carrying on where you left off, I would think your only option is to close down gracefully.

You should first rollback any transactions in progress and revert any uncommitted buffers. Something like this:

lnSessionCount = ASESSIONS(laSessions)
FOR lnI = 1 TO lnSessionCount  
  SET DATASESSION TO laSessions(lnI)
    DO WHILE TXNLEVEL() > 0
      ROLLBACK
    ENDDO 

    lnTableCount = AUSED(laTables)
    FOR lnJ = 1 TO lnTableCount
      IF CURSORGETPROP("Buffering", laTables(lnJ,1)) > 1
         TABLEREVERT(.T., laTables(lnJ,1))
      ENDIF 
    ENDFOR 
ENDFOR

I can't be sure the above code will work if the connection to the data has been lost (it's not something that can easily be tested), but I would think it will be OK.

After that, just issue ON SHUTDOWN, CLEAR EVENTS and QUIT, which is probably what you already do in your error-handler.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[mibosoft]

Hmmm, I don't work with transactions and buffers (which I perhaps should) but maybe I can use some ideas from your code anyway.
Thanks'
Micael

 

[Mike Lewis]

If you don't use transactions or buffers, then you should just shut the app down. You risk breaking the integrity of the database (for example, if the user was part way through entering a series of related records when the problem occurred), but that's always going to be the case when the app raises an error during a data-editing session.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[mibosoft]

I can't find any good solution to shutdown gracefully when the connection to the database is lost.

My error-handler catches error 1105 "Error writing to file" like this:

...
case AERRINFO[1] = 1105
close databases all
release windows 'grid_form'
retry
otherwise
...

Immediately after, another error window pops up with the same error message. This popup has a "Cancel", "Ignore" and "Help" button and from what I understand, this is a system error message. If you click "Ignore", the database closes fine and there are no problems opening another database and keep working. The problem is that the system error popup allows the user to issue "Cancel" which is not good.

Why does the system error appear at all when my "ON ERROR" handler catches the same error? How can I suppress it?

/Micael

 

[ilyad]

As far as I know this error is not always trappable. Take a look at Thread ID:1075915 at

http://www.UniversalThread.com

for some ideas.

 

[Mike Lewis]

Micael,

It doesn't make sense to do a RETRY after you do CLOSE DATABASES ALL.

The error that triggered the original message was caused by a failure to read data. If you close your databases, and then try to read the data again, it is certain to fail again.

You got the Cancel / Ignore / Help message rather than a custom message because that second error-occurred within the error handler. That's the way it works.

Instead of the Retry, you should be doing ON SHUTDOWN, CLEAR EVENTS and QUIT.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[mibosoft]

My first attempt was using ON SHUTDOWN, CLEAR EVENTS and QUIT but this hangs the application.

It sounds logical that the second error occurs within the error handler. It also explains why the RETRY command followed by clicking "Ignore" stopped the application from hanging. The problem is that I can't find a way to close the database and/or quit the application without getting the second error (Cancel/Ignore/Help). It pisses me of that it is so hard to take care of the simple fact that the physical connection to the database location is lost.

 

[Mike Lewis]

Micael,

One possible reason that ON SHUTDOWN / CLEAR EVENTS / QUIT didn't work is that there was a form open at that point. The QUIT causes the form to close, and that in turn fires code in the form's Destroy and Unload events. That code could be doing something to interfere with the closedown process.

One sure way of closing the application without it hanging or getting an error is like this:

DECLARE Integer ExitProcess IN WIN32API
ExitProcess()

However, I'd consider that a last resort only. Ideally, you should try to figure out why it is hanging.

I'd also remove the CLOSE DATABASES ALL. If you've lost the connection, you won't be able to close the databases, and besides, there's no point, given that you are closing down anyway.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[mibosoft]

Correct, I'm testing this with an open form that has a grid in it (kind of worst case scenario). I did some tests earlier with un-commenting all code in the unload and destroy events but will try this again.

Thanks' for taking time,
Micael

 

[mibosoft]

Mike,
ExitProcess() made it for my app. Without it, I get a system error for each table in the database when issuing quit.

Worth a star for me, thanks'
Micael

 

[Mike Lewis]

Micael,

Glad it worked. I use it in my own error handler, and also in my routine that forces users to log out of the system. Thanks for the star.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk