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 wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Tableupdate() Suggestion/Advice

Status
Not open for further replies.

IForgot

Programmer
Mar 20, 2002
122
US
I have a Client/Server application where the Server side is another box (Linux) running an active real-time application unto itself.

I capture a "snap-shot" of a Remote table, make calculations based on the data, determine a "delta" for specific record values and then need to write the results back to the server table.

My Remote View of the server's table is Table Buffered
CURSORSETPROP('Buffering',5,'view1')
so as to not compromise the real-time data which might change during my application's processing. I then work on a local copy of the view until ready to write back.

My write back consists of doing a
SELECT view1
REQUERY()
of the server table's view and then a
REPLACE ALL view1.field WITH view1.field + local.delta;
FOR <criteria>
Finally I follow this immediately with a
=TABLEUPDATE(2,.F.,'view1')

However with the nRow parameter of the TABLEUPDATE() command set to 2 I do not know if an error occured (such as if the Remote record was in-use during the update) resulting in loss of data update.

Under the circumstances and considering that only some records of the table require updating, is there a better way to approach this issue so as to ensure the update of all appropriate record's data?

Your suggestions and advice are greatly appreciated.

Thanks,
I_Forgot
 
This is from the help. Very similar to your code but some suddle changes.

1. It uses the name of the table as the 3rd parm of th CURSORSETPROP function.

2. TABLEUPDATE just passes in a .T. parm

See if this helps.


CLOSE DATABASES
CREATE TABLE employee (cLastName C(10))
SET MULTILOCKS ON && Must turn on for table buffering.
= CURSORSETPROP('Buffering', 5, 'employee' ) && Enable table buffering.
INSERT INTO employee (cLastName) VALUES ('Smith')

CLEAR
? 'Original cLastName value: '
?? cLastName && Displays current cLastName value (Smith).

REPLACE cLastName WITH 'Jones'
? 'New cLastName value: '
?? cLastName && Displays new cLastName value (Jones).

= TABLEUPDATE(.T.) && Commits changes.
? 'Updated cLastName value: '
?? cLastName && Displays current cLastName value (Jones).


Jim Osieczonek
Delta Business Group, LLC
 
Thanks for the reply.

I already have
SET MULTILOCKS ON

Remember that the Server is running a Real-Time application so it can change its table's data very quickly.

Consequently I cannot do an INSERT because it might compromise the REAL table updates that could be going on during my processing.

I must update the REAL table record's values with the new Delta value (negative, positive, or zero) based on my application's calculations against the data &quot;snap-shot&quot;.

This Delta value needs to be added to the REAL table's current values, not replace them with
seconds-old data + delta values

There must be a way to perform the TABLEUPDATE so as to trap on an error, and then re-try the record update until successful, and then go on to finish the remainder of the record updates.

Again, your suggestions and/or advice are most welcome.

Thanks,
I_Forgot
 
What if you just do a TABLEUPDATE(.T.) on the table after you set the buffer mode to 5 and multi-locks on?

Jim Osieczonek
Delta Business Group, LLC
 
What server backend is?
Maybe you can simply achieve this using triggers/stored proedures at server side.
 
I_Forgot,

Tableupdate() will return a value of .T. when it has successfully committed your changes. If you want to reprocess this in the event that it returns .f. you could use a simple do loop checking the value every time and continuing until it is .T. (give yourself some kind of escape hatch in case you end up in an infinite loop). As Jim has suggested, using TABLEUPDATE(.T.) will force the changes and this may or may not be desirable for you. If you go with =TABLEUPDATE(1,.F.,'view1', aryError) then at least you could see if there were any conflicts/errors via error array - if there were conflicts because the data had changed since you did your requery then you could tablerevert()/requery() your view and redo your replace before trying to commit your changes. Seems it would be safest given the very dynamic nature of the data you are working with. Just my thoughts for what they are worth.

Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top