How to check if backend data still exists for a buffered data

[CrimsonJio]

Hi guys,

We're getting VFP 2172 error. The program is a multi-user environment.

Scenario (all tables have buffering):
1. 1st user is accessing a table with notepad. Then, accesses another table for a while.
2. 2nd user deletes the record (currently viewed by 1st user) and performs table update.
3. 1st user returns to the table and encounters the error since the buffered data no longer has a corresponding "data-link" in the backend.

Is there a way to verify or check if the back-end data for a buffered data exists?

From what I know, there must be some "mechanism" in which foxpro identifies which row/data in the back-end corresponds to the buffered data.

TIA.

 

[Olaf Doschke]

Never had that error, from the help description you use a memo as (part of) a key to reidentify the record.

This leads to some questions:
1. Does the table have a memo field?
2. Do you talk of a buffered table and tableupdate()?
3. Do you talk about a view or cursoradapter and tableupdate()?

If the error description is not misleading I would say you don't us a buffered table. Foxpro would rather reidentify the source record via recno() or the primary key than via a memo field as key.

So from the error description perspective it looks like you handle a view here, that may be in the default WhereType 3 - key+all modified fields. This means the record to update is reidentified by all modified fields. But the memo could only be a problem if not fetched in the first place and then it could also not be among the modified fields.

Ok, I'm out of explanaitions, maybe you first share your code with us and describe in more detail what you're doing and what command leads to that error.

Bye, Olaf.

 

[Mike Lewis]

Your normal error handling should deal with this situation.

Presumably, the first user is issuing a TABLEUPDATE() at some point. The program should check the reply from that function. If it is .F., use AERROR() to find out the cause of the error, then proceed accordingly.

That should enable you to detect the situation you described. Of course, how you recover from it is entirely up to you.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[CrimsonJio]

The table has optimistic row buffering and has a primary key and a memo field. The issue is not encountered on tableupdate but when verifying data (i.e. if empty(memo)).

When I checked the view, there is no record. Though if I checked by doing reccount(), it would show 1. It seems that any process, method or function that will try to access the buffered data causes this issue.


Mike,

OK. So other from using error handling, there is no way for me to identify if the "link" is lost?

This may be tougher than I thought. The system already has an ONERROR event that is called for client reporting (error log creation and email).

 

[Olaf Doschke]

Any code? Can we see any code?
You talk of table and then view. So are you handling a view here or the table?
Any code?

For example you could open the view in the designer and let it ouptu the definition code. Rightclick and Show SQL. I'd be interested in all code including all the dbsetprop() statements.

Bye, Olaf.

 

[Mike Lewis]

CrimsonJio,

You said "When I checked the view, there is no record". This is the first time you said anything about a view. In view of what Olaf said about memo fields, you might want to try setting FetchMemo to .T. (using DBSETPROP()).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[CrimsonJio]

Sorry, my bad. They are remote views.

I tested it with the fetch memo marked and I don't have encounter the error anymore. Though there still seems to be issue with regards to saving it, I think we could work around it.

Thanks guys.