Field not updating unless re-selected.. 1

[steve4king]

Why is it that the Found() block updates ctra.invoice, but the else block, does not? (unless I select ctra right in front of it)

SELECT cinv
SET ORDER to cinvuid

SELECT ctra 
SET ORDER TO Ctrauid
GO TOP 

SCAN
  SELECT cinv
  SEEK cuid
  IF FOUND()
      IF ctra.invoice != cinv.iinvoice
	 REPLACE ctra.invoice WITH cinv.iinvoice 
  	 DELETE
      ENDIF 
			
   ELSE
      replace ctra.invoice WITH '      0' &&doesn't work

   ENDIF 	 
ENDSCAN

..
ELSE
	select ctra
	replace ctra.invoice with '      0' &&works
..

 

[GriffMG]

I don't know why your example doesn't work, but it's often good practise to select a work area before doing replaces.
It just seems clearer to me - it's what I've done since VFP3

Which version of VFP are you using?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

You can also do REPLACE field WITH value IN alias, and that's much better than REPLACE alias.field WITH value.
REPLACE works not, if EOF() is .f., and that's the case when the previous LOCATE doesn't find anything and FOUND() is .F., FOUND() simply is NOT EOF().

REPLACE always works in the current workarea, so it always checks EOF(), which in itself checks for end of file of the current workarea. Even if you specify REPLACE alias.field WITH value REPLACE does not check EOF(alias), it checks EOF().

There is a direct reason of course, as you can't replace values, when the record pointer does not point to a record but at the end of a file. There is a reason in the bigger picture, because REPLACE also can replace in many workareas, if you set relations. This is very complicated, if you're not used to it and if you would want to replace in many workareas at once, also SQL won't give you a feature for that, but I'd always prefer SQL-Updates or TABLEUPDATE() anyway. REPLACE is fine for single field changes, much more convenient than UPDATE-SQL with a WHERE id = ..., but I'd alsway SELECT workarea before REPLACE as best practice. And never use alias.fieldname for REPLACE. It's tempting, it's better coding style, but as you see it may not work, the best practice for me is REPLACE field WITH value IN alias, and still SELECT alias previous. Double safety.

Bye, Olaf.

 

[Olaf Doschke]

>REPLACE works not, if EOF() is .f.
Inverse logic, REPLACE does not work if EOF() is .T. of course.

 

[GriffMG]

That's interesting Olaf, so if the CURRENT work area is in the EOF() state, VFP doesn't do a replace in
ANY other work area unless you either select it or use the IN.

That does rather explain why I adopted the SELECT X... REPLACE ... approach years ago and it's never
let me down!

I think it looks neater too - but that might be because I'm used to it!

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

Yes, that's how it is. This way, the current and "main" workarea tells VFP, if the whole replace makes sense. If you work with relations, they typically should all start from or point to the selected workarea, because otherwise the relations wouldn't position on the correct secondary records, and if the main alias is at EOF you also point to no records in secondary aliases or in the worst case to any really nonrelated records you wouldn't want to update. The IN clause makes that workarea the main workare, even though VFP doesn't switch to it.

Well, I'm not absolutely sure, because we talk of advanced and nonstandard usage of REPLACE, but you can easily make up some test code.

Of course, if you're not at EOF() in the current workarea, but at EOF() in other workareas, there also is no update of fields possible, so in a way of course EOF(alias) still also influences REPLACE.

Bye, Olaf.

 

[Olaf Doschke]

Short sample code...

Create Cursor curSor1 (id i, cData C(100))
Create Cursor curSor2 (id i, cData C(100))

* CurSor2 is the active workarea now
? Alias()

Append Blank In curSor1

? Eof()
Replace curSor1.cData with "hello, world"
? _tally
? curSor1.cData

Replace cData with "hi, world" in curSor1
? _tally
? curSor1.cData

Select curSor1
Replace cData with "hello, tek-tips"
? _tally
? curSor1.cData

So indeed as I said "The IN clause makes that workarea the main workarea, even though VFP doesn't switch to it." In the second REPLACE VFP doies check EOF("curSor1"), because of using the IN clause.

Bye, Olaf.

 

[steve4king]

Very interesting Olaf.
I didn't realize that the EOF check worked that way. Thanks.
I've been writing VFP code for a few years now.. I don't know how I've succeeded thus far without knowing this.. It's somewhat foundational.

Directly selecting an alternate workarea prior to each replace isn't as pretty, but defining "in workarea" looks like a great way to handle this.

(How do I change my title? "IS/IT--Management" was somewhat accurate.. five years ago haha)

-Stephen

 

[Olaf Doschke]

>I don't know how I've succeeded thus far without knowing this

I had the same thought, when first reading about this. You typically LOCATE and then REPLACE in the same workarea, which of course works. I tend to always use IN clause, not only for REPLACE. And as I said I wold even rather both ELECT the workarea and use IN. It's not needed, but if you work on code, sometimes added lines or removed lines would cause code to stop working. Of course you do test and debug and would find it. You also only get very neglectible slower, if you program more verbose.

In regard of your tek tips title, I don't know. It's not part of the profile, I think you can' change that.

Bye, Olaf.