Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Why use: GO RECNO() 1

Status
Not open for further replies.

AllCaz

Programmer
Dec 5, 2000
12
0
0
US
I'm updating someone else's code and I keep running into the statement:

GO RECNO()

My first instinct was to rip it out - why move the record pointer to the record you're currently on? But I have a feeling that it's there for some reason, maybe it's the solution to some weird bug - does anybody know?
 
Hi
You know what my friend, I am really sick and tired from this assumption that This must be here for a reason
and finally I find out that this is here because some people like to write spagetti code.
Anyways, as far as I know this does not fix any bug, at least bug I know.
My advice is to leave it alone just enhance it with this line of code to make sure you are safe if your record pointer in the gost record or BOF or EOF so you don't get out of range run time error.
Code:
IF BETWEEN(RECNO(),1,RECCOUNT())
  GO TO RECNO()
ENDIF
Thanks,
Walid Magd
Engwam@Hotmail.com
 
Hi,
When you update underlying table of a GRID (i mean RecordSource). You must use GO RECN() to force the GRID to refresh. (This is a bug, just happend sometime)

Jimmy
mailto:nhan_tiags@yahoo.com
 
Another reason is to re-align the parent-child relationships with that file in case the active record of the child files has been changed with code.

Don
dond@csrinc.com

 
Hi!

One more reason - any record movement for cursor used for view in row buffering mode cause view updated automatically. GO recno() also cause automatic update, but without record movement...

Refreshing of BROWSE window, but only current row instead of all rows, is another reason.

As about spagetti code... Well, I remember that fine old years when in FP2.6 or even older we had no other ways than just use some tricky code. Of course, from the VFP6 point of view such code looks as spagetti, specially for VB programmers.


Vlad Grynchyshyn
vgryn@softserve.lviv.ua
The professional level of programmer could be determined by level of stupidity of his/her bugs
 
To expand on the statements above. In the OLD days before Database Containers, relationships between tables had to be set manaully. When a relationship is first set, the record pointer in the child.dbf is not moved from the current record until the record pointer in the Parent.dbf is moved. (this is still true today)

So assume this situation
USE CUSTOMER order ID
seek "00001111"
use CUSTCODE order ID in 0
set relation to ID into CUSTCODE

Where is the record pointer in CUSTCODE?
It Is still on the first record in the index or record ID = "00000001"
But if you did
Select CUSTOMER
skip 1
skip -1
the pointer in the CUSTCODE.DBF was now on record ID = "00001111"
****
So the thing most people did was
***
in the days of dBase and FoxPlus
select 0
USE CUSTOMER ORDER ID
select 0
USE CUSTCODE ORDER ID
select CUSTOMER
goto bottom
set relation to ID into CUSTCODE
goto top
do while xx
....
enddo
..
With the event of FOXPRO came all the fun toys in the browse command so it became:
select 0
USE CUSTOMER ORDER ID
USE CUSTCODE ORDER ID in 0
goto bottom
set relation to ID into CUSTCODE
goto top (or) seek "whatever"
browse
****
then came the FoxPro screen generators became popular so to refreash a screen with a browse, in the set up area of the screen this was use
USE CUSTOMER
lnCustRencno = RECNO()
use CUSTCODE order ID in 0
set relation to ID into CUSTCODE
then in the generator code section came to refresh the browse
select CUSTOMER
goto lnCustRecno
browse
***
With the event of VFP came the GRID and the DBC, so also came the
goto RECNO()
to make sure the records in the child tables were pointed to the same record as the parent table.
***
I hope this brief look into history did not bore you but help you and other people understand the reason behind the goto RECNO() statement. Sorry about showing off my age. David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644
 
Is there a filter on your table that has to be activated ??

A filter is only activated when the record pointer is moved.

HTH,
Weedz (Wietze Veld)
veld4663@exact.nl

They cling emotionally to code and fix development rather than choosing practices based on analytical assesments of what works best.

After the GoldRush - Steve McConnell
 
Thankyou all for your responses! Now I realize that GO RECNO() is being used to refresh the parent-child relationships, but I think I'll add tests for EOF and BOF. I've been using FoxPro for 7 years and I'm still learning new tricks.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top