TABLEUPDATE() Headache

[spayne]

OK, a lot of threads out there deal with this issue. I think I've looked at all of them. My problem is that my code works most of the time. Here's the code:

IF !USED("v_myview")
SELECT 0
USE v_myview
ENDIF
SELECT v_myview
=CURSORSETPROP("BUFFERING",5)
SCATTER MEMVAR BLANK

m.field1 = data
m.field2 = data
m.field3 = data

SELECT v_myview
APPEND BLANK
GATHER MEMVAR
=TABLEUPDATE(.T.,.T.)

Basically, that's it. Not much more going on. There are only three users that will ever access this view. Two will write to the table and the third will extract data for printing reports. One data entry person never has a problem, but the other one seems to be unsuccessful maybe 10-15% of the time. In some of the instances, I know for a fact, that neither of the other two users are accessing this table. Oh, and yes, MULTILOCKS is ON. Any suggestions?

Thanks,
Steve

 

[mspratt]

Are all the users using the same config.fpw file?

Regards,

Mike

 

[spayne]

Yes they are using the same config.fpw file.

I suppose I could also add I am using VFP 6.0 with no service pack and Visual Maxframe Professional framework. I have only been here a few months and I'm just getting familiar with VMP, but I don't think that would be the problem.

Also, both work stations have identical hardware, but the one that is good is using WinXP while the other has Win98SE.

 

[rgbean]

Update to Service Pack 5 - it makes no sense not to. There was so much "fixed" in the intervening five SPs!

Rick

 

[mspratt]

Agree (as always) with Rick, not to mention it may fix your problem.

More detail as to the error might be helpful.

Regards,

Mike

 

[spayne]

I agree with the upgrade. It's been on my to do list. As far as more details as to the error, I don't know what to say. Like I said in my first post, it's very basic code. And there is no error message...it just doesn't update a small portion of the time. So far, I can determine no pattern or any ryhme or reason as to which records are not updated.

My next step will be to determine if there is some pattern. I was just hoping someone out here had a "been there, fixed that" solution for me.

 

[TedMcCoin]

Steve,
you could try to change your buffering settings eg:

=CURSORSETPROP("BUFFERING",2)

TABLEUPDATE also provides an ErrorArray, syntax
TABLEUPDATE([nRows [, lForce]] [, cTableAlias | nWorkArea][, cErrorArray])

have you tried that ?

Ted

 

[mspratt]

I would set Buffering to 3 and SKIP -1, SKIP instead of TABLEUPDATE(). If you don't test success of TABLEUPDATE() with buffering set to 5 the system won't generate an error so you'll never know it failed (even with an Update Conflict).

If you continue to use Buffering 5, you can test the success of the TABLEUPDATE.

llSuccess = TABLEUPDATE(.T.,.T.)
IF llSuccess
   MESSAGEBOX("Success")
ELSE
   MESSAGEBOX("Failure")
ENDIF

Regards,

Mike