Record is out of range

[jhonny03]

plz help me on this error..
here is the part of my code with the error "record is out of range"

IF nPos > 0 
	GOTO (nPos)
ENDIF

tnx in advance...

 

[Olaf Doschke]

The record nPos doesn't exist, then.

Since you don't specify the alias, this might be due to having the wrong active workarea.
It's recommended to use the IN clause of commands to not get this wrong.

Bye, Olaf.

 

[Mike Lewis]

Record out of range" means what it says. You are trying to go to a record number which doesn't exist in the table. That could happend because the number is negative, zero, or higher than the highest record number in the table. In this case, you are explicitly testing for greater than zero, so the number must be higher than the highest in the table.

You should amend your code as follows:

IF BETWEEN(nPos, 0, RECCOUNT())
  GOTO (nPos)
ENDIF

But that doesn't necessarily explain the error. As Olaf points out, you also need to make sure that you are operating on the correct table. So you need to go one step further:

IF BETWEEN(nPos, 0, RECCOUNT("MyTable"))
  GOTO (nPos) IN MyTable
ENDIF

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I'd prefer Mikes second approach.

But in both approaches you avoid an error that otherwise hints on doing something wrong. That's the wrong kind of silencing and stabilizing an application. If you want to move to nPos in some table and this code now does not do so, as it sees nPos > RECCOUNT(), the move isn't done and that doesn't error. So far, so fine, but you might afterwards operate on a different record than you think in the table, as there was no goto. Working on the current record instead or RECNO() = nPos can have all kind of bad consequences, just because you prevented the error.

Your real error must be somewhere further up the drain, previously. Either you set nPos wrong or you work in the wrong workarea, the wrong table. If you find out why nPos>reccount() or that you switched to a wrong workarea, then you may fix that and the code could stay. To be prepared for the general case of a wrong nPos you could also put this into a function SAFEGOTO(nPos), which returns .F. when it didn't go to nRec, but that also won't bring you to fixing the real bug further up the drain somewhere.

It has some advantage to work with code in any active workarea, it's generic and all you need is SELECT sometable beforehand. In that mindset you still have to be cautious its the correct workarea, but you then obviously don't want to use IN clauses but profit from the default behaviour of many commands to work in one current workarea. Then you could still make it more safe by put the GOTO in TRY CATCH and check if RENO()=nPos after the GOTO:

TRY
  GOTO nPos
CATCH
  *
ENDTRY
IF RECNO()=nPos
   * Do something at nPos
ELSE
   * Record not found.
ENDIF

Ideally you find out why your nPos or your current workarea were wrong. Especially if it's code from someone else, you don't easily changre all of it to work with a new paradigm to eg always specify IN tablename. I do the latter, as very few code can be used on all tables, your code normally is specific to a certain table and thus can be as verbose as it can be to work on that table and not accidentally work on some other table just by a flaw in selecting the wrong workarea.

Bye, Olaf.

 

[Olaf Doschke]

Another topic: What could have happened is, that you remember a current position nPos=RECNO(), then PACK the DBF and when GOTO nPos the table is shorter and the nPos record has moved to a lower record number. You best remember and SEEK back to an identifier field, primary key of the table. There is a SEEK() function that like the proposed SAFEGOTO() function does return .T. or .F., when finding or not finding the specified key value. It needs an index to seek in, but that should exist for a primary key anyway.

Bye, Olaf.

 

[jhonny03]

tnx guys..