Hi Tim,

I hope you had a great weekend!

> Did you try verifying these tables to make sure that they aren't corrupted
> ?

Yes - this is happening at various sites, and no table corruptions can be
found.

> There's only two places that a 15002 error could occur.  One is the remote
> session comms compression, and the other is the BLOBs.  If you say that
> the remote sessions are not using compression at all, then that leaves the
> BLOBs.  I double-checked the DBISAM source code last night just to be
> sure, but if you have the RemoteCompression property set to 0, then there
> is absolutely no way that a compress/decompress error should occur unless
> the comms stream is corrupted in such a way during login as to cause the
> server to think that the remote session is requesting a compressed
> connection. But, that would have to be some pretty selective comms
> corruption.

The TDBISamSession remotecompression property is set to zero at all sites.
The corruption never appears to occur straight away, but normally after a
while of running the program (or running the report multiple times), and
thus would eliminate the comms stream corruption during login possibility. I
have verified the tables many times to confirm that there is no corruption.

If the decompression script should only execute when the compression level
is turned on (ie > 0), then why would we receive the same error with BLOB
fields if they were corrupt, if compression isn't used? (ie, is there
another trigger besides the remotecompression setting that causes
decompression scripts to be ran?)

Also, is there somewhere else in the application where compression is used
(ie, for temporary tables, or memory tables) regardless of the compression
level property?

Thanks for your help Tim, I know this is not an easy issue for either of us,
but please bear with me

Cheers

Adam

Adam,

<< I hope you had a great weekend! >>

Well, I played hockey for 3 hours on Sunday morning and now I'm walking
funny, but other than that, I'm great

<< If the decompression script should only execute when the compression
level is turned on (ie > 0), then why would we receive the same error with
BLOB fields if they were corrupt, if compression isn't used? (ie, is there
another trigger besides the remotecompression setting that causes
decompression scripts to be ran?) >>

I was assuming that it could possibly be the compressed BLOB fields that you
said existed, but weren't being used in this particular situation.  I'm just
trying to cover all possibilities, including the fact that you're accessing
something that you think that you're not.  I don't have your source code
here to look at, so I have to theorize.

<< Also, is there somewhere else in the application where compression is
used (ie, for temporary tables, or memory tables) regardless of the
compression level property? >>

No, just those two places.

I'm getting a new DBISAM build ready, and this is one of the incidents:

http://www.elevatesoft.com/incident?action=viewrep&category=dbisam&release=4.26&type=f&incident=2574

Are you perhaps using encrypted connections at all ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Good Morning Tim,

> << I hope you had a great weekend! >>
>
> Well, I played hockey for 3 hours on Sunday morning and now I'm walking
> funny, but other than that, I'm great

Well, at least  you're walking! I've watched a bit of hockey footage on TV
before and crikey!  

> << If the decompression script should only execute when the compression
> level is turned on (ie > 0), then why would we receive the same error with
> BLOB fields if they were corrupt, if compression isn't used? (ie, is there
> another trigger besides the remotecompression setting that causes
> decompression scripts to be ran?) >>
>
> I was assuming that it could possibly be the compressed BLOB fields that
> you said existed, but weren't being used in this particular situation.
> I'm just trying to cover all possibilities, including the fact that you're
> accessing something that you think that you're not.  I don't have your
> source code here to look at, so I have to theorize.

The only BLOB fields that have compression (that I recall) are graphic
fields that are in other tables unrelated to the reports having this
problem. (ie, not called up at all when these errors occur). There may be
another table in there with compression, but definitely not the tables used
within the SQL.

> << Also, is there somewhere else in the application where compression is
> used (ie, for temporary tables, or memory tables) regardless of the
> compression level property? >>
>
> No, just those two places.
>
> I'm getting a new DBISAM build ready, and this is one of the incidents:
>
> http://www.elevatesoft.com/incident?action=viewrep&category=dbisam&release=4.26&type=f&incident=2574

Cool - I'll give this a shot and see what happens. As for FastMM4, I have
used this, but also taken it out, with no effect in the past to these
errors.

> Are you perhaps using encrypted connections at all ?

Unfortuantly not. I am however using the OnQueryProgress property, and it
"seemed" when I stopped using this the problems lessened, but didn't
elminiate. I'm wondering if it has something to do with the load on the CPU
/ application at the time (but this is only guessing). I simply mention it
just incase it triggers something new in your mind.

Once again, thanks for your ongoing assistance.

Cheers

Adam.

Adam,

<< Well, at least  you're walking! I've watched a bit of hockey footage on
TV before and crikey!  >>

We don't play checking hockey, so it's a lot more tame.  Plus, we're all 32+
years old, so we don't quite move as fast as those 20-year olds on TV.

<< Unfortuantly not. I am however using the OnQueryProgress property, and it
"seemed" when I stopped using this the problems lessened, but didn't
elminiate. I'm wondering if it has something to do with the load on the CPU
/ application at the time (but this is only guessing). I simply mention it
just incase it triggers something new in your mind. >>

Do you have any timers in your application ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> << Well, at least  you're walking! I've watched a bit of hockey footage on
> TV before and crikey!  >>
>
> We don't play checking hockey, so it's a lot more tame.  Plus, we're all
> 32+ years old, so we don't quite move as fast as those 20-year olds on TV.
>

Aah - slightly different story then. Good to see your.... 'responsible'.
<vbg>

> << Unfortuantly not. I am however using the OnQueryProgress property, and
> it "seemed" when I stopped using this the problems lessened, but didn't
> elminiate. I'm wondering if it has something to do with the load on the
> CPU / application at the time (but this is only guessing). I simply
> mention it just incase it triggers something new in your mind. >>
>
> Do you have any timers in your application ?

Aaah Yes! Apart from a few timers that just clear a status bar after x
seconds, I have an 'IDLE' timer (to determine when the application has been
idle for a number of seconds) which then trigger other timers (such as
'refresh' timers which refresh selected datasets / datamodules if they're
open at that time.

Cheers

Adam.

Adam,

<< Aaah Yes! Apart from a few timers that just clear a status bar after x
seconds, I have an 'IDLE' timer (to determine when the application has been
idle for a number of seconds) which then trigger other timers (such as
'refresh' timers which refresh selected datasets / datamodules if they're
open at that time. >>

That information along with the OnQueryProgress information indicates that
there may be an issue with datasets being accessed re-entrantly via the
timers.  Are you causing the application to process the message loop in the
OnQueryProgress event handler via Application.ProcessMessages, or something
similar ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> << Aaah Yes! Apart from a few timers that just clear a status bar after x
> seconds, I have an 'IDLE' timer (to determine when the application has
> been idle for a number of seconds) which then trigger other timers (such
> as 'refresh' timers which refresh selected datasets / datamodules if
> they're open at that time. >>
>
> That information along with the OnQueryProgress information indicates that
> there may be an issue with datasets being accessed re-entrantly via the
> timers.  Are you causing the application to process the message loop in
> the OnQueryProgress event handler via Application.ProcessMessages, or
> something similar ?

I call object.refresh (to refresh the painting on a progressform), but do
not do any OnQueryProgress's within the OnQueryProgress event. I do have
some application.processmessage's AFTER the query is opened, like:

myquery1.open;
application.processmessages;

.... just incase that (or the .refresh'es) could be the problem?

Best Regards

Adam.

Adam,

<< I call object.refresh (to refresh the painting on a progressform), but do
not do any OnQueryProgress's within the OnQueryProgress event. I do have
some application.processmessage's AFTER the query is opened, like:

myquery1.open;
application.processmessages;

... just incase that (or the .refresh'es) could be the problem? >>

Not the Refreshes, since they use Update to directly send a message to the
control in question.

Anything that will cause the message loop to be processed will cause the
timers to fire, and if they are accessing any components that use the same
session then it is possible to run into some serious issues with the remote
comms.  DBISAM (and ElevateDB) assume that the client communications with
the database server are serialized.  Anything that disrupts that scenario
could cause it to completely lose track of what is going on with the comms.

It would work something like this:

Query1 is executed, causing the OnQueryProgress to fire
OnQueryProgress causes the message loop to be processed
Timers now fire, trying to perform an operation using the same session

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

I hope you had a great weekend!

<snip>

> Query1 is executed, causing the OnQueryProgress to fire
> OnQueryProgress causes the message loop to be processed
> Timers now fire, trying to perform an operation using the same session

Thanks for that information. With my queries, I actually call a procedure to
open them. (Basically OpenQuery(MyQuery)). Because of this, I will be able
to add a flag when opening queries and remove the flag when the query has
opened. With this, I can then check this flag in my timers and make sure the
timer doesn't do anything if the flag is true, just incase the timers are
somehow triggering through something I'm not aware of.

I'll make this change, and let you know the progress.

Once again, thanks for all your help!

Cheers

Adam.

Adam,

<<I hope you had a great weekend! >>

I pulled my groin at hockey Sunday morning, so apart from a little trouble
walking, I'm fine.

<< Thanks for that information. With my queries, I actually call a procedure
to open them. (Basically OpenQuery(MyQuery)). Because of this, I will be
able to add a flag when opening queries and remove the flag when the query
has opened. With this, I can then check this flag in my timers and make sure
the timer doesn't do anything if the flag is true, just incase the timers
are somehow triggering through something I'm not aware of.

I'll make this change, and let you know the progress. >>

Cool, thanks.  That will at least rule out the possibility that there's
something executing when we don't want it to be executing.

--
Tim Young
Elevate Software
www.elevatesoft.com