>>>>>Thanks Lutz,
>>>>>
>>>>>I don't know how a second class got in there. Deleted the obsolete one.
>>>>
>>>>If a classlib was hacked, i.e. opened as a table and then records manipulated (like I had to do today, after so many years), everything's possible. Also possible that you don't remember because it was done years ago and you noticed now.
>>>
>>>Dragan,
>>>
>>>Good guess I think. I hacked the vcx a long time ago while re-engineering classes. Obviously something invalid was left there by mistake, but since VFP apparently uses the class version defined LAST within the vcx ( strange but true ! ), and that class worked well, I didn't notice the problem. Recently, when I used Fernando's excellent foxbin2prg in a round trip (bin2text and then text2bin) it apparently selected the class version defined FIRST in the VCX as the valid class. That class had an error and it showed up. Just deleted the incorrect class.
>>>
>>>Thanks to all. Sorry I didn't answer sooner.
>>>
>>>Alex
>>
>>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.