Chuck,

My previous advice stands. If you're using INDEXSEEK() you need to pass in the lMoveRecordPointer parameter, otherwise use SEEK().

You can remove all the "SET DELETED ON" lines and put it once at the end. Not a problem to set it ON if it's already ON. Even better is

LOCAL lcOldDeleted
lcOldDeleted = SET DELETED()
SET DELETED OFF
*!* Do stuff here with deleted records
SET DELETED &lcOldDeleted

That way if someone decides to change the whole app to run with a different DELETED() setting, nothing breaks and you don't have to comb through the whole thing cleaning up the code. It's a good habit to have to code that way for DELETED, EXACT, CENTURY, etc. when you temporarily need a special setting.

It's difficult to say exactly, but there are always problems when one moves from FPW to VFP and continues to code in FPW. It sounds like your supervisor is steering you toward bad habits by still using memory variables rather than insisting that you learn to do things a new way. Due to the politics where you are, if I were you I would save email or whatever that shows the supervisor telling you to do it this way. Most job descriptions specify that you code according to in-house standards and if anyone questions your coding style you can pull out the email and say that you were coding according to standards.

At the same time, I would seriously look for another opportunity. I know your current job pays well, but living in Hell because it pays the bills is not a good idea in the long term. Look for an opportunity to become the best software developer that you can be, especially if you can work with some other people who really know what they're doing.


>Sorry to post my 'whole' code in here just like that. Reason is I believe it would be easier to see what I have done to the whole 'Save' button (snipped out the ThisForm.Refresh stuff at end). Please feel free to change anything you see fit.
>
>As I am looking at this once again, I think I am repeating something or just something is not right? If you don't mind, please look it over. BTW, when the form comes up, the PERSON table is already selected. The 'mode' are 'A' for the 'Add' button and 'E' for the 'Edit' button. There are only three fields (m.id, m.name, m.logon) the the user can change and the two other hidden fields (uplog and updated) are for tracking who changed the data. Yeah, I did NOT want to use memory variables, but this is what my supervisor wants (who thinks that VFP is like the DOS dBASE). If I have to change the textbox from memory variable to real fields (m.id, m.name, etc), that's fine.
>
>Again, sorry if this whole code posting is offense. Seriously, I think I am losing my mind in this position, am considering seeking a different job so I can do VFP more liberaty
>
>I did read the whole thing about INDEXSEEK() and still trying to understand it completely (it does not move the record pointer, but it can move it too...)?
>
>Chuck.
>
>>Chuck,
>
>>Looks like you need the following:

>>IF INDEXSEEK(m.ID, .T., "Person", "ID")
>>    Messagebox('This Person ID is already in the database.'+CHR(13)+ ;
>>        'Duplicate Records will not be saved!',64)
>>
>>    *!* m.ID is already correct.
>>    *!* "Refresh" Name and Logon, even if they are the same
>>    *!* who cares if they are already the same
>>    m.Name = Person.Name
>>    m.Logon = Person.Logon
>>ELSE
>>    *!* Do whatever you do with a new record
>>ENDIF