FoxPro database connector - trapping a 'record in use' message

Author

trapping a 'record in use' message

Andy Trezise

2005-11-29, 8:25 pm

Hi

I am getting a number of these error messages thrown up by my application
which runs across our corporate LAN and has a dozen or so users online at
any one time.

Generally I buffer all the updates (mode 4) and rlock() whereever possible.
With hindsight I would probably have done things differently but I want to
try and avoid a heavy rewrite.

I'm having difficulty finding the offending line(s) of code as my error
routine only gives me the error number and message.

I was wondering if there was a function to tell me what table the error
occurred on. Maybe that way I can zone in on the offending bit of code and
trap it more effectively. I don't suppose I can zone straight to the
offending line of code - I tried compiling with line numbers but still
couldn't get them to display.

2005-11-29, 8:25 pm

If you use forms then the line and method is part of the error event

I have an error procedure that I call with
ON ERROR DO myerror WITH ERROR(), MESSAGE(), MESSAGE(1),
RETPRG(ASTACKINFO(la
_stack)), LINENO(), RETMEM(), RETSTAT()

In my main procedure file I have the functions needed for above

FUNCTION RETPRG

LPARAMETERS ln_level

LOCAL i, n, lc_program

LOCAL ARRAY la_prg(1)

n = ASTACKINFO(la_prg)

IF TYPE("ln_level") # "N"

ln_level = n - 1

ENDIF

i = MIN(ALEN(la_prg, 1),ln_level)

lc_program = ""

FOR n = i TO 1 STEP - 1

lc_program = lc_program + "Callstack Level: " + ALLTRIM(STR(la_prg(n
, 1),4,
0)) + CHR(13) + CHR(10)

lc_program = lc_program + SPACE(4) + "Program: " + ALLTRIM(la_prg(n, 2)) +
CHR(13) + CHR(10)

lc_program = lc_program + SPACE(4) + "Module/Obj: " + ALLTRIM(la_prg(n, 3))
+ CHR(13) + CHR(10)

lc_program = lc_program + SPACE(4) + "M/O Src File: " + ALLTRIM(la_prg(n,
4)) + CHR(13) + CHR(10)

lc_program = lc_program + SPACE(4) + "Line Number: " + ALLTRIM(STR(la_prg(n
,
5),4, 0)) + CHR(13) + CHR(10)

lc_program = lc_program + SPACE(4) + "Source Line: " + ALLTRIM(la_prg(n, 6))
+ CHR(13) + CHR(10)

NEXT

RETURN (lc_program)

FUNCTION RETSTAT

LOCAL lc_tmpf1, lc_select, lc_ret

lc_tmpf1 = SYS(2015) + ".txt"

DISPLAY STATUS TO FILE (lc_tmpf1) NOCONSOLE

lc_ret = FILETOSTR(lc_tmpf1)

* USE

ERASE (lc_tmpf1)

IF TYPE("lc_ret") # "C"

lc_ret = "N/A"

ENDIF

RETURN (lc_ret)

FUNCTION RETMEM

LOCAL lc_tmpf1, lc_select, lc_ret

lc_tmpf1 = SYS(2015) + ".txt"

DISPLAY MEMORY LIKE * TO FILE (lc_tmpf1) NOCONSOLE

lc_ret = FILETOSTR(lc_tmpf1)

ERASE (lc_tmpf1)

IF TYPE("lc_ret") # "C"

lc_ret = "N/A"

ENDIF

RETURN (lc_ret)

Finally all that myerror does is take the parameters and writes them to a
table including SYS(0) to get the offending machine and a DATETIME()

To avoid locking conflicts I usualle use RLOCK() or FLOCK() at the beginning
of the save/update routine.

DO WHILE !FLOCK("alias1") OR !RLOCK("alias2") && etc lock all the files
involved in the update
UNLOCK ALL
WAIT "Attempting to lock files ... " Window timeout gn_timeout && or
something like that where gn_ timeout is a timeout value You can also put
some code there so the client is not stuck here forever in case some file
stays locked for a long time
ENDDO

<Here goes your file update code>

UNLOCK ALL && make sure you do that or some client might get stuck

IMPORTANT!! do not use code that waits for user imput between the lock and
unlock statements or outputs to a printer or to the screen

for example

<locking code>

REPORT FORM .....
or
= MESSAGEBOX(.......) etc
UNLOCK

Will leave the files locked indefinitly if the user for example displays the
report on his screen and goes home or for lunch or sends it to the printer
and the printer is not available.

Now what I have not figured out yet is some way to find out what machine is
locking it.

"Andy Trezise" <andy@work.com> wrote in message
news:O5o7gfS9FHA.1032@TK2MSFTNGP11.phx.gbl...
> Hi
>
> I am getting a number of these error messages thrown up by my application
> which runs across our corporate LAN and has a dozen or so users online at
> any one time.
>
> Generally I buffer all the updates (mode 4) and rlock() whereever
possible.
> With hindsight I would probably have done things differently but I want to
> try and avoid a heavy rewrite.
>
> I'm having difficulty finding the offending line(s) of code as my error
> routine only gives me the error number and message.
>
> I was wondering if there was a function to tell me what table the error
> occurred on. Maybe that way I can zone in on the offending bit of code and
> trap it more effectively. I don't suppose I can zone straight to the
> offending line of code - I tried compiling with line numbers but still
> couldn't get them to display.
>
>

Sponsored Links