Yossi,

1. You should never have any table that does not have a primary key. You will only regret it later, and not having primary keys is a bad habit to get into.

2. flock is not related to any record updating commands; iow you do not lock a table manually, vfp will lock the record the REPLACE command is using, or will lock the header during an append blank.

3. There are often reasons to use append blank, especially during transactions that might be rolled back. To say never use it, and always use insert into , is an over generalization. Times when either is best.

>Craig, thanks. I just need a resource that you can point me to that has the information such as 'FLOCK() is bad in multiuser scenarios', so that I don't have to keep on bothering gurus like you.
>
>As far as the primary key, in this particular case I didn't need see a need for one - it's just a log that can be filtered by date/time. Is there something wrong with this?
>
>>FLOCK() is bad in multiuser scenarios. There's no reason to lock a file to do an INSERT INTO. You comment raises the question of how your code generates the primary key.
>>
>>>Are you saying that with INSERT INTO, I don't need flock()?
>>>I guess that 'Log file' is inaccurate. It's a list of emails that have a lSent field. If the previous attempt was unsuccessful and it is successful now, I want to update the lSent to .t.
>>>
>>>

>>>PROCEDURE UpdateEmailLog(tcText, tcCustno, tcDisposition)
>>>
>>>LOCAL lnSelect, llUpdated
>>>
>>>lnSelect = SELECT()
>>>
>>>SELECT emails
>>>
>>>llUpdated = .F.
>>>
>>>DO WHILE !llUpdated
>>>
>>>	IF FLOCK()
>>>		APPEND BLANK
>>>		REPLACE em_body WITH tcText, ;
>>>			em_datetim WITH DATETIME(), ;
>>>			em_custno WITH tcCustno, ;
>>>			em_disptn WITH tcDisposition
>>>
>>>		UNLOCK
>>>		llUpdated = .t.
>>>	ENDIF
>>>
>>>ENDDO
>>>
>>>
>>>SELECT (lnSelect)
>>>
>>>RETURN
>>>