Hi,

I'm using BDS 2006 and DBISAM 4.24, client server. The same problem
happens on different computers (Windows 2000Pro and Windows XP).

The problem:

I have a table with a small number of fields (record size is 56), one
field is a Memo. Only one index, primary, on an AutoInc field.

In my application, there is a secondary thread that creates a session,
a database and the required table.

The secondary thread basically colects tons of messages (small log
records), in a threadsafe list, which then periodically saves to the
table. The table is only accessed by this thread. Actually all the
database stuff in this application happens in this thread only.

From time to time an Access Violation is thrown when the memo field is
assigned a string, code looks like this (FLogMessage is a TMemoField):
     FLogMessage.AsString := Rec.LogMessage;

MADexception stack always points to when some Modified property is set
somewhere in DBISAMtb (TDBISAMBlobStream.Destroy).

I wrapped the above assignment and catch the AV, and have 3 loops, so
actually the updates always succeed in those 3 loops, but I am bothered
by the AV, still.

Anyone seen anything like it? Am I doing something wrong, shall I do
anything special for the memofield?

Note: if I change the memo to a regular string field all is fine,
however since most stuff I want to log might have empty strings, I need
a memo in order to optimize the disk usage (I am talking about 1GB/day
of stuff).

--
TIA

Lucian

> From time to time an Access Violation is thrown when the memo field is
> assigned a string, code looks like this (FLogMessage is a TMemoField):
>       FLogMessage.AsString := Rec.LogMessage;

Just in case that's an issue, no, I do not assign empty strings to the
memo, one more line of code above that...

 if Rec.LogMessage <> '' then
   FLogMessage.AsString := Rec.LogMessage;

--
TIA

Lucian

Lucian,

<< In my application, there is a secondary thread that creates a session, a
database and the required table.

The secondary thread basically colects tons of messages (small log
records), in a threadsafe list, which then periodically saves to the table.
The table is only accessed by this thread. Actually all the database stuff
in this application happens in this thread only.

From time to time an Access Violation is thrown when the memo field is
assigned a string, code looks like this (FLogMessage is a TMemoField):
     FLogMessage.AsString := Rec.LogMessage;

MADexception stack always points to when some Modified property is set
somewhere in DBISAMtb (TDBISAMBlobStream.Destroy). >>

Is it reproducible ?  If so, could you send me a project that does reproduce
it ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

> I wrapped the above assignment and catch the AV, and have 3 loops, so
> actually the updates always succeed in those 3 loops, but I am
> bothered by the AV, still.

seems I was wrong, actually the blob becomes corrupted and I have to
repair the table after all.


Lucian

> Is it reproducible ?  If so, could you send me a project that does
> reproduce it ?

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,

Lucian

Tim,

Works fine in a simple application. Looks like I'm rather doing
something bad.

thx,

Lucian

> Is it reproducible ?  If so, could you send me a project that does
> reproduce it ?

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.

--
Lucian

> when I use a string instead of
> a memo

A memo is a wrapper on a windows control, and the VCL is not usable from
background threads, only from the main thread. I'd say you are lucky it
works at all. You can't use visual controls in background threads at all.

/Matthew Jones/

> You can't use visual controls in background
> threads at all.

You misunderstood or I was not clear. I wasn't talking about the VCL
"memo" control. I am talking about having a memo versus a string field
in the table. At run time, within a thread, I retrieve the field using
Table.FieldByname and that's what I use. There are no UI controls
involved at all. When the table has a string field my app runs without
any troubles. When instead I use a memo field, my app crashes several
times an hour. When I change the field type in the table, the only and
only one change that I make in my app is to match accordingly the field
(practically it's a one word change: I switch TStringField to
TMemoField). Why would this work differently... that's what puzzles me.

I hope is clear now.

regards,

Lucian

Ah, right. Phew! 8-)

I'd double check the basics first - that you have the session ID unique
and that the database et al all use the right session. Then I'd go for a
cut-down version for Tim. His support when I had a similar issue was
superb, and he took my almost full app, cut all the parts he couldn't
compile and passed it back saying it worked fine, I put the key code back
in that made it show the issue, and a day later a fix was available. It
was a horrible threading thing IIRC that I was triggering by hammering it
and adding, deleting and querying all at the same time constantly. Anyway,
he did a great job of condensing it once I'd got it repeatable.

/Matthew Jones/