>Mr. Zonneveld, I'm currently working on the local view and learning its capabilities, thou i've read some several issues that the tables "dbf" or the container dbc sometimes get's currupt or the indexes needs to be reindex when a power failure occurs or if an abnormal shutdown takes place.
>
>Acutally the reason why I choose to use the Cursor Engine is because once i've opened the table i automatically update my cursor the closes the table immediately. The only problem with that approach is that the data is not LIVE, so whenever I attempt to Update or Delete the ROW I still have to Open the table and check if there were changes or if another user is currently using the same row.
>
>Mr. Zonneveld can you give me some advice on how I can avoid this curruption issues on my DBC or DBF Files.
>
>Thank You Very Much.
>Marlon Estrelon

First, let me briefly explain buffering - just in case you are not aware of the following.

Buffering allows you to apparently make changes to fields, with commands like REPLACE or GATHER, or with fields directly bound (.DataSource) to the field, but the changes are not immediately saved to disk. VFP buffers them.

Changes are saved to disk with TableUpdate(). You can also undo changes with TableRevert().

IIRC, a view is automatically opened with buffering enabled.

If you work directly with tables, it is highly recommended that you enable buffering. See CursorSetProp("Buffering", ...), in the help.

For the corruption, I recommend you use FLUSH after saving to disk. If you use buffering, that would be after a TableUpdate().

Also, if your OS uses write-cache, turn it off for the hard disk that contains the VFP data.

For your other question: If you use optimistic buffering, TableUpdate() will automatically lock the record, while VFP tries to save changes. Also, VFP will check if another user has made changes in the meantime. The standard behaviour (see the parameters for TableUpdate()) is that changes are NOT saved if another user made changes in the meantime. I recommend that in this case, you inform the user, and perform a TableRevert().

If the record can't be saved, TableUpdate() will return .F.

Use aerror() to find out, why the record can't be saved. Here is an example:

if TableUpdate()
  wait window nowait "Record saved successfully."
else
  local laError(1)
  aerror(laError)
  MessageBox("Can't save record." + chr(13) + chr(10);
    + "Error #" + transform(laError(1) + " message: " + laError(2))
endif