>>>>You have notified Fernando so he can fix this?
>>>>
>>>>The behaviour is, that VFP simply deletes the old record while safing the class and appends new records to the VCX. So VFP makes shure to get the last - valid - record. For example it does not care about SET DELETED. In older versions of VFP the deleted records in the VCX where never packed.
>>>
>>>Hi Lutz,
>>>
>>>I did copy Fernando on that last message, but I will bring it to his attention again.
>>>
>>>I thought of it as *my* problem rather than in Fernando's, but I guess in a way it can be dealt with by foxbin2prg.
>>>
>>>Thanks for the suggestion,
>>>
>>>Alex
>>
>>FoxBin2prg should, under no circumstance, destroy a binary. So it must deal in the expected way, iow with the bottommost recordset of 2 classes with the same name.
>>
>>We never know what strange setting we might run into.
>
>
>Hi:
>
>I may add this autofix, but I'm not 100% sure that the good record will be *allways* the one with the bigger Timestamp.
>
>If I add this autofix, I could add a switch to disable it, just in case someone do not want it, but the problem here is FoxBin2Prg taking a decision by it's own.
>
>Another possibility is to ask the user if want to autofix. That may be a better approach...
>
>
>What do you think

I think the last valid one is the record(set) with the higher recordnumber. For all I understand (and see in this thread) this will be choosen by VFP in case of collision.

I would not use timestamp, since there is nothing to sync the times of two computers. (and the vcx will not care about timezones, for example)

Possibly you can raise an allert if you see the same class twice in a vcx and let the user fix the problem on it's own.
Or generate both classes but with different names () on users wish ...), so the code is kept. It would need to fix the vcx afterwards (at least to pick the right class) but it will not be destructive.