>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.

Craig Bernston may easily have written such a resource. However, since you were already attempting the append blank in a loop, the flock was simply not needed. APPEND BLANK and INSERT must be handling the locking for you or they would never work in a multi-user environment. I've rarely used flock(). By the way - I only write multi-user apps. I don't do anything whatsoever that might be requiring single-user - except pack/index/backup maintenance.

>
>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?

Absolutely there's something wrong with not having a primary key. You should have one on every table, or by definition, you have a heap, not a table. How do you plan to update the record to set lSent to .T. The quickest way is to find a single record by it's primary key.

>
>>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
>>>