Record numbers changing without reason 2

[mmerlinn]

In FoxPro 2.6 this is happening to me:

? RECNO('a') && Returns 1578
? RECNO('b') && Returns 341
? RECNO('c') && Returns 1531

CREATE VIEW temp
SET VIEW TO temp

? RECNO('a') && Returns 1
? RECNO('b') && Returns 340
? RECNO('c') && Returns 1530

Needless to say, keeping record pointers correct is a royal pain.

Any suggestions on why this is happening and what I can do about it?



mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[alvechurchdata]

You can't do OUTER JOIN in FPD2.6

I forgot :-(



Geoff Franklin

http://www.alvechurchdata.co.uk

 

[mmerlinn]

Hey all,

The typo grinch got me again. Yes, SET SKIP TO Table_B is correct.

As I get time, I will examine these responses and see what works for me. And, of course, I will let all of you know what I finally decided to do and why.

As for the foibles in the FP commands, as I find out what they are I write UDFs to circumvent the problems. For example, I seldom use SELECT(tablename) anymore, I use TSELECT(tablename) instead and avoid most gotchas with SELECT(). Others include LLCREATE() instead of FCREATE(), ATXLEFT() instead of LEFT(AT(blah),blah) {faq184-5975}, etc. And even FMT(expr [, expr]) instead of ALLTRIM(string), ALLTRIM(STR(number)), DTOC(date), etc, which happens to be the most used and most useful UDF I have.




mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[mmerlinn]

Lol.

I don't see how to UDF out of this one either. Except possibly a UDF that automatically keeps the linked tables updated. I already have UDFs that load and save everything in the data table tree automatically, so maybe I could expand on them. Like WSAVE([tablename]) saves all info in 'tablename' and all info for all child, gchild, etc tables that are related to 'tablename'. Unfortunately, there is a bug in that UDF in that it will not correctly update the lowest related node in any branch if that node is one-to-many to the next higher node. Since that is not a problem at the moment, I have not taken the time to find the bug and correct it.

One thought about using a temp cursor. To make the underlying tables easier to add and update, I have been thinking of just making the temp cursor a file of record numbers for the records in the underlying tables, and using it to access the records, rather than making a huge table of duplicate information to use. Any ideas about the viability of that?

s


mmerlinn

"Political correctness is the BADGE of a COWARD!"