VCursor Hosing Database

[Chuck Pelto]

Hi Ruslan,

On Jul 17, 2006, at 1:33 PM, Ruslan Zasukhin wrote:

> On 7/17/06 8:37 PM, "Chuck Pelto" <cbpelto at pcisys.net> wrote:
>
> Hi Chuck,
>
>> Working in RB2006, I've got a V4RB2 database I've set up to manage
>> data in the system.
>
> Version of Valentina ?
>
>> When I open up a window, the VTable is used to populate the various
>> editable control objects in the window. Things work fine.
>>
>> However, if I want to limit the records being viewed by establishing
>> a VCursor, when the VCursor populates these same objects, it hoses
>> the database.
>>
>> Is there something I need to do  before using data from the VCursor
>> to populate the fields that are already populated by information from
>> the VTable? SetBlank()? Or something like that?
>
> No idea. I need see what you are doing
>
>> The nature of the hosing is that when I close the application, it
>> refuses to close. I have to force-quit. After I've force-quit the
>> application, the database is HUGE and 'corrupted'. Despite the fact
>> that no records were supposed to have been changed in this.
>
> Please send to me project that reproduce this..

I appreciate the offer of help. But I managed to find the problem  
myself.

It relates to a clash between my methodology and the way REALbasic  
deals with TextChange events in EditField objects.

It seems that when I went from using data in the VTable to that in a  
VCursor the TextChange event of an EditField would be triggered. This  
apparently was causing information in the record that was in the  
VCursor to be overwritten on the record seen from the VTable with a  
recID of nil. Or so I think at the moment. And when I tried to close  
the app, the database was so confused it wouldn't close and grew to  
almost 100 times its original size, before a Force-Quit would stop  
things. Of course, the database was toast and had to be replaced.

Building a filter mechanism into the TextChange event that would  
preclude updating data in editable fields if the text change was the  
result of a record change seems to have solved the problem.

Regards,

Chuck