Errors with dbUseArea(), dbCreate(), fOpen(), etc. 
Author Message
 Errors with dbUseArea(), dbCreate(), fOpen(), etc.

Hello,

In a large application I'm maintaining, users sometimes get an error
indicating that some file action didn't work out as planned. They get this
problem at several points in the program, but at very irregular intervals.

The problem seems to pop up when a file needs to be created or opened. There
are no problems when a file is open. The commands that fail are various:
most problems occur with fOpen() and fCreate() where a filehandle of -1 is
returned, but even commands like dbUseArea() or dbCreate() sometimes fail
(create error, errors stating that the file does not exist, etc.).

There are sufficient rights, diskspace, memory, filehandles, etc. because
when I rewrote some functions to loop a couple of times (with a short pause)
whenever the create/open function failed, the application didn't crash (at
that point) anymore.

The problem seems to be related to Windows95/NT because the application
never had this problem in DOS. The problem also seems to be related to the
disk/network activity of other applications that are running on the
pc/network. When another application is opening and closing a lot of files
(for example "Find Files Or Folders" with a text scan), the problem gets
worse.

The application is written in Clipper 5.2e with Class(y) and some users even
use ADS. It runs under Windows95/NT workstations with Netware (3.1x and 4.x)
and NT fileservers. The problems occur in every situation but seem to be the
worst on an NT workstation.

QUESTION
 Is there something like a internal time out in Clipper? Does Clipper assume
that there is a file-problem when it takes to long to open/create a file
(because the pc/file server is too busy handling some other request)? Or
does Windows95/NT report to a process that it's request is not yet completed
because of to much activity and is this misinterpreted by Clipper?
Do I have to rewrite every generic Clipper file function into something with
a loop? Is it possible to create an errorhandler that would retry some
actions a couple of times (but not idefinitly, because there really could be
something wrong with a file), without users having to act on problems (the
application also runs at night when there is no one around to answer
questions)

Thanks,

Mark de Waal



Sat, 29 Jul 2000 03:00:00 GMT  
 Errors with dbUseArea(), dbCreate(), fOpen(), etc.



Quote:
>Hello,

>In a large application I'm maintaining, users sometimes get an error
>indicating that some file action didn't work out as planned. They get this
>problem at several points in the program, but at very irregular intervals.

>The problem seems to pop up when a file needs to be created or opened. There
>are no problems when a file is open. The commands that fail are various:
>most problems occur with fOpen() and fCreate() where a filehandle of -1 is
>returned, but even commands like dbUseArea() or dbCreate() sometimes fail
>(create error, errors stating that the file does not exist, etc.).

>There are sufficient rights, diskspace, memory, filehandles, etc. because
>when I rewrote some functions to loop a couple of times (with a short pause)
>whenever the create/open function failed, the application didn't crash (at
>that point) anymore.

>The problem seems to be related to Windows95/NT because the application
>never had this problem in DOS. The problem also seems to be related to the
>disk/network activity of other applications that are running on the
>pc/network. When another application is opening and closing a lot of files
>(for example "Find Files Or Folders" with a text scan), the problem gets
>worse.

>The application is written in Clipper 5.2e with Class(y) and some users even
>use ADS. It runs under Windows95/NT workstations with Netware (3.1x and 4.x)
>and NT fileservers. The problems occur in every situation but seem to be the
>worst on an NT workstation.

>QUESTION
> Is there something like a internal time out in Clipper? Does Clipper assume
>that there is a file-problem when it takes to long to open/create a file
>(because the pc/file server is too busy handling some other request)? Or
>does Windows95/NT report to a process that it's request is not yet completed
>because of to much activity and is this misinterpreted by Clipper?
>Do I have to rewrite every generic Clipper file function into something with
>a loop? Is it possible to create an errorhandler that would retry some
>actions a couple of times (but not idefinitly, because there really could be
>something wrong with a file), without users having to act on problems (the
>application also runs at night when there is no one around to answer
>questions)

>Thanks,

It's not Clipper that's responsible for network time-outs, it's the
client network shell.  If you use Novell Client32, you have complete
control over the behaviour of the shell, but the MickeySlop client is
brain-dead in comparison.  Make sure you use v2.2 of Client32 as
previous versions have problems with performance/stability.

HTH

--
Nick Ramsay



Sun, 30 Jul 2000 03:00:00 GMT  
 Errors with dbUseArea(), dbCreate(), fOpen(), etc.

[responding to Nick Ramsay's reply as I missed the original post]



Quote:
>In a large application I'm maintaining, users sometimes get an error
>indicating that some file action didn't work out as planned. They get this
>problem at several points in the program, but at very irregular intervals.

>The problem seems to pop up when a file needs to be created or opened.
>There are no problems when a file is open. The commands that fail are various:
>most problems occur with fOpen() and fCreate() where a filehandle of -1 is
>returned, but even commands like dbUseArea() or dbCreate() sometimes fail
>(create error, errors stating that the file does not exist, etc.).

>There are sufficient rights, diskspace, memory, filehandles, etc. because
>when I rewrote some functions to loop a couple of times (with a short pause)
>whenever the create/open function failed, the application didn't crash (at
>that point) anymore.

>The problem seems to be related to Windows95/NT because the application
>never had this problem in DOS. The problem also seems to be related to the
>disk/network activity of other applications that are running on the
>pc/network. When another application is opening and closing a lot of files
>(for example "Find Files Or Folders" with a text scan), the problem gets
>worse.

>The application is written in Clipper 5.2e with Class(y) and some users even
>use ADS. It runs under Windows95/NT workstations with Netware (3.1x and 4.x)
>and NT fileservers. The problems occur in every situation but seem to be the
>worst on an NT workstation.

>QUESTION
> Is there something like a internal time out in Clipper? Does Clipper assume
>that there is a file-problem when it takes to long to open/create a file
>(because the pc/file server is too busy handling some other request)? Or
>does Windows95/NT report to a process that it's request is not yet completed
>because of to much activity and is this misinterpreted by Clipper?
>Do I have to rewrite every generic Clipper file function into something with
>a loop? Is it possible to create an errorhandler that would retry some
>actions a couple of times (but not idefinitly, because there really could be
>something wrong with a file), without users having to act on problems (the
>application also runs at night when there is no one around to answer
>questions)

It is possible to build in a "timeout" into a custom ERRORSYS error
handler, as shown in this fragment from the top of a modified
ERRORSYS.PRG.  It stores the date and time a timeout/retry operation
begins in a static variable:

==================================================

func DefError(e)

// STATIC VARIABLE BELOW TO TRACK FILE OPEN TIMEOUTS
static ntimetrack      

local i, cMessage, aOptions, nChoice

        // by default, division by zero yields zero
        if ( e:genCode == EG_ZERODIV )
                return (0)
        end

/* THIS CODE ADDED TO RETRY FILE
    OPEN OPERATIONS FOR FIVE SECONDS */

        if e:gencode == EG_OPEN .and. e:canRetry

           if ntimetrack == nil  // first pass, set timeout tracker

              // store the time we first got into this mess
              // so we can control how long we retry
              ntimetrack := ;
              val( dtos( date() ) + ;
              strtran( time(), ":" ) )

           endif

      // retry once per second for 5 seconds
           if val( dtos( date() ) + ;
           strtran( time(), ":" ) ) - ntimetrack   <  5

              // one second timeout
              inkey( 1 )

             // retry operation
              return ( .t. )

      endif

   endif

   // release retry tracker now that we are done with it
   ntimetrack := NIL

/* END OF ERRORSYS MODIFICATIONS */  

        // for network open error,
        // set NETERR() and subsystem default
        if ( e:genCode == EG_OPEN .and. e:canDefault .and. ;
        ( e:osCode == 32 .or. e:osCode == 5 ) )

                NetErr(.t.)
                return (.f.)

        end

... [remainder of errorsys.prg]



Mon, 31 Jul 2000 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. RDD Error DBCMD /1015 ARGUMENT ERROR DBUSEAREA

2. dbcmd/1015 argument error dbcreate

3. clipper 5.01 -> 5.3 : Argument error: DBUSEAREA

4. DBUSEAREA() Internal Error

5. DBCMD/1015 Argument error: DBUSEAREA

6. dbusearea() Internal Error 1010

7. FOPEN error on pc with NT workstation

8. DOS Error 5 (FOPEN, Summer '87)

9. fopen() run time error R6001

10. I need help with an fopen() error

11. DbCreate()

12. DBCREATE params

 

 
Powered by phpBB® Forum Software