Hi Luzt:

> I would not use timestamp, since there is nothing to sync the times of two computers

You are wrong on this, the timestamp have nothing to do with synching, but only to know "which record is newer". In a normal scenario, this field is correctly updated, but can happen (I saw this) that two or more records have the same timestamp, then you can't know which one is newer, and in this case you must use the 2nd.way of resolution I've mentioned in another post.

Physical position of the record can't be used too, because that's what a situation of corruption code or data means, you can't assume "a logical" way of behavior.



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