It does have the basics all right I do use DBISAM in multithread
apps on a regular basis. However this is first time I needed to use a
memo field ... so heavily.

The problem with testing is I have to wait hours to see if they do have
a problem or not. Currently I do run another test on my app, using a
string field. It's been running for about 5 hours - if it was using a
memo field, it would have raised an AV in about 1 hour. Only when I get
back home I'll be able to run again small test apps. So, 2 more hours
to run the test, based on string field.

I will probably do the same thing as you did, cutting down my app, if
simple test won't do.


thanks,

Lucian

Lucian,

<< I'm still puzzled why my app works fine when I use a string instead of a
memo. If it would have threadsafe issues it should crash aproximately
at the same rate (1-2 times per hour), but it doesn't crash at all.I'll try
to run more tests aside of the app, maybe I can reproduce the error. >>

String and memo fields are implemented in an entirely different fashion.
Reading a memo field involves all sorts of I/O on the .BLB file, along with
a lot of code setting up the I/O, etc.

--
Tim Young
Elevate Software
www.elevatesoft.com

Lucian,

<< I was afraid you're going to ask that. It happens pretty often in my app,
however I can not send you the big thing. I will try to write a test app and
let you know. >>

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Something weird just hapened: I fired another test with my app, before
checking if the field is declared as memofield or stringfield (just
came from a visit and rushed to test it again) ... and the thing is the
table has a memo field and the application is declaring a tstringfield
and it worked. I actually than stoped the test and made sure there is a
mismatch, I recompiled and yes it works in this configuration:

- the table has a memo field.
- the application declares a stringfield which then is mapped to the
memofield using FieldByName and all the other code is left untouched so
it updates the field using .AsString call.

Is this a bug or a feature or a side effect, is this normal?
In any case the AV showed up after 9 minutes.

And it will not show up in a simple application, damn ;(

thx,

Lucian

One thing I did was remove external triggers, and made it go mad doing its
thing. That made the several hours to repeat problem into a "within a
minute" problem.

/Matthew Jones/

Lucian,

<< Is this a bug or a feature or a side effect, is this normal? >>

No, it shouldn't work at all, and my guess would be that you're mistaken.  A
TMemoField descends from TBlobField, which is the only way that you can get
data out of a memo field.   A TStringField cannot do it since it knows
nothing about how to deal with BLOBs.

--
Tim Young
Elevate Software
www.elevatesoft.com

> way that you can get data out of a memo field.   A TStringField
> cannot do it since it knows nothing about how to deal with BLOBs.

Probably the exceptions were absorbed somewhere, because indeed this
doesn't work here, on a small test app.

--
Lucian

Lucian,

Do you have something like MadExcept? The extra details & stack trace it
gives might help you find the source of your error.

Sean

Lucian wrote:
>> way that you can get data out of a memo field.   A TStringField
>> cannot do it since it knows nothing about how to deal with BLOBs.
>
> Probably the exceptions were absorbed somewhere, because indeed this
> doesn't work here, on a small test app.
>

> Do you have something like MadExcept? The extra details & stack trace
> it gives might help you find the source of your error.

Yes I do. If you read the original post you'll see the exception
happens in the same spot (TDBISAMBlobStream.Destroy) in my application.
However, the app is rather big, and I fail trying to get the same
exception to happen in a small test app. In any case, since nobody
seems to have such problems I blame my code and changed the approach in
my app. I no longer use a memo field (I don't quite have time to prove
who's right or wrong).

thx,

Lucian