[V4RB2] 2.0.4fc5 crash - more info

[Ruslan Zasukhin]

On 6/9/05 4:55 AM, "Kem Tekinay" <ktekinay at mactechnologies.com> wrote:

Hi Kem,

> I determined yesterday that my crash occurred when I tried searching my
> database while there was also a loop in a socket that was adding records.

So you have 2 threads?
You need semaphore access to database in this case.

> It turns out that I can crash the app, and corrupt the database, very easily
> by doing this, even though I can't figure out why. It's not a thread, after
> all, and I'm pretty sure this was not an issue before.

Before - when? With 1.x or 2.0.3 ?
Do you use cursors or API ?

> As a test, I let my app run and add records overnight without a problem.
> This morning, after about 22,000 records, I stopped the loop, quit the app,
> and restarted it. So far so good.

ok
 
> I then started searches and, while they were successful, I found that
> searches run on a compressed VText field in related records were taking
> almost two minutes each even though the field was indexed by words.

What you mean in related? You do join on 2 tables?

> Previously, I had reported that such searches had taken around 2 seconds on
> even more records. The only difference between that test and this one (apart
> from the different version of V4RB2) is that the VText field is now
> compressed.

Project ?
 
> Thinking that perhaps the indexes were damaged, I quit the app, deleted the
> ".ind" file, and restarted my app. After a bit of a delay, my app started,
> but the index file was less than half the size of the one I had deleted.

This is normal. When you rebuild index usually it is less than index built
during work. 
 
> I ran a search on a non-compressed VVarChar field in the master records and
> that worked. I then tried the related, compressed VText field, but got an
> Exception ("compressor error"). My app crashed and I could not start it
> again. When I opened the data files in VStudio, all of my tables, and the
> data, were gone.
> 
> Ruslan, does any of this give you a clue as to what may be going on? And
> should searches on compressed VText fields take longer than ones on
> non-compressed VText fields?

Kem, 

Please do next. 

1) Build again some db in 10,000 - 20,000 records.

2) make copy of it.

3) try search it from viSQL. Also slow ?

4) if yes send us db. And query you do.

5) also we will try reproduce .ind problem.



-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]