Tableupdate()

[BJCZ79]

Hi,

I have on question. I have VFP6.
I use this code. After function tableupdate() selected table change row. I used debag and watch window. I used Buffering mode 5

select "table1"
Replace Price with 1
tebaleupdate(.T.)

Why it happends?

Thanks

 

[Mike Lewis]

Your code looks fine. What exactly is the problem?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[BJCZ79]

If I use this in transaction:

local IDT1

select "table1"
Replace Price with 1
IDT1 = table1.Id
tebaleupdate(.T.)

Select "Table2"
go top
locate for Table2.IdT1 = Table1.id
replace SumPrice with Sumprice + Table1.Price

After tableupdate Table1 change current row. IDT1 = 5 and table1.id = 6.
I think it shoud be like this : table1.id = 5.
But I don´t know why.

 

[Mike Gagnon]

So what you are saying, I think, is once you use tableupdate() the record pointer moves? That is normal behavior, check the help file on tableupdate()

If table buffering is used and multiple records are updated, TABLEUPDATE( ) moves the record pointer to the last record updated.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[BJCZ79]

Thanks

That´s the problem. I'm doing some replace before. But this time the previous replace change the row after the current row in the table. Tha?s why it set to other row.

 

[Mike Lewis]

Mike,

Add IN clause to REPLACE command ALWAYS!!!!

Just out of curiosity, why ALWAYS!!!! ?.

I believe it's good practice to use the IN clause wherever possible, but why do you particularly insist on it in this case?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

I'm with Mike Y on this... it ensures that someone hasn't selected some other table in a piece of code before it in the event of some maintenance years (or even days) down the road. Even for the person who did it. It's just like the old "Always "SELECT <Table>" prior to a "GATHER MEMVER" from the old 2.6 days, just to make sure you ALWAYS have the right table before gathering distructive to it...

It is good practice, but it is really more than that for ensuring long term maintainability. ALSO, I think the ol' gotcha is still around that if you are on EOF() on another table, and REPLACE in a table other than that table the update will not happen. Was a strange old Fox bug, don't know if its still around or not.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Mike,

I totally agree with both you and Scott on this. It's just that ... well, you say you don't insist on it, but when you wrote ALWAYS in capitals with four exlamation marks, I got the impression that you were particularly anxious to make the point .. as if it was even more important in the case of REPLACE than with commands in general.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Mike Lewis]

Mike,

strongly recommend it in ALL!!!! cases.

Ah, well. That explains it. YES!!!!.

(I'm glad we've both got a sense of humour.)

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk