Hi,

Thanks so much for the explanations on the differences in the 'append froms'. But guess what. It turns out that the problem resulted from table header corruption. Here is what I found:

1) I could not reproduce the problem on my machine
2) I went to the client and found that it could be reproduced consistently on their machine.
3) I did some tests and debugging after the 'append from dbf('currespmatr') and found that the 29 rows in question APPEARED to be added. I did a browse of respmatr after the append from and saw the rows, and saw that the record count was updated appropriately (from 610 to 639) Then there was a llretval=tableupdate(.t.,.t.,'respmatr') statement. llretval was .t.
Then an END TRANSACTION.
4) After the transaction completed I closed the program, and browsed the table. The rows were gone. The record count was back down to 610.
5)In other applications, I had previously had what I have heard is a 'known' type of table corruption whereby the table header/record count is not updated properly, and that foxpro 'appears to add a row', but in fact the row is not added.
6)So I tested an append blank into the table from the command window. This worked. So I thought my table corruption theory was shot.
7) But then, just to be sure, I copied the table data to a temp table. Then did a DROP TABLE. Then I recreated the table structure from scratch. Then I appended the data back in.
8)Finally, I re-ran the program and all was back to normal.

9) I discussed it further with the client and found out that they had had a system crash (probably the app was open at that time) due to a problem with the CD ROM- and got a blue screen of death.

At this point the client is up-in-arms about the stability of the system and VFP in general. I need to give them a plan for assuring the stability of the data.

I absolutely need to study the issues surrounding this type of corruption. I have seen posts on it here before. But I need to revisit them.

I need to know whether the primary cause of this type of corruption is from system crashes, or whether there are other techniques, etc. that may contribute to it, and should therefore be avoided.

I also need to investigate some of the system tools out there for assessing/fixing dbf corruption. In the past I have been aware of foxfix, dsalvage and recover. In the past when I had this particular type of corruption, the tools I used did not detect it.

Finally, I would like to determine why the append worked in a non-buffered command window mode but not when the table was buffered, with tableupdate and a transaction. This seems like a very subtle, insidious type of corruption.

Any further help that you or others might provide in this area would be greatly appreciated.


TIA




>Good question. Append from < TableName > always looks for the table TableName.dbf on the disk regardless if it's open or not already. Because of that

Append from respmatr
>   and
>Append from ( dbf('respmatr')  )

are not the same. The first one references respmatr.dbf and foxpro'll look for it starting with default directory and so on. The second one references a table open under alias 'respmatr'. It could be the same as the firts one or the different one. If you've only one table respmatr.dbf on the path and it's open under alias respmatr than you can use eaither one otherwise second one is preferable.
>
>The following append could "fail" if cresphdrid<>lc_cresphdrid

Append from respmatr for cresphdrid=lc_cresphdrid
>

>>Thanks Sergey,
>>
>>It seems even less likely then that the append failure has anything to do with the fact that it is a cursor.
>>
>>In your opinion which append from statement below is more likely to fail?
>>
>>Should I also be using append from dbf('respmatr') in the one that is appending from the table, or is it adequate the way it is?
>>
>>Respmatr is a table that is opened in the form, in the data environment.
>>
>>>The CREATE CURSOR command always creates a cursor as a temorary file on a disk.
>>>
>< SNIP >
>>>>
>>>>I have similar code as follows:
>>>>
>>>>=afields(larespmatr,"respmatr")
>>>>Create cursor currespmatr from array larespmatr
>>>>Select currespmatr
>>>>Append from respmatr for cresphdrid=lc_cresphdrid &&respmatr is a table in the database
>>>>
>>>>Then later on:
>>>>
>>>>select respmatr
>>>>append from dbf('currespmatr')
>>>>
>< SNIP >