Adam,

<< I have placed the server log in the binary newsgroups under 'Server log
for Tim'. >>

There's a lot of access denied error messages for temporary tables in the
server log.  Are they using AV software on the terminal server machine ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Jan,

<< I might be way off base on this however when you are performing these
queries, do you query any BLOB or memo fields for data? The reason I am
asking is because in dealing with BLOB and Memo data types, I believe
the database engine will allocate memory buffers for these and if your
query will overrun those buffers, you might run into the situation where you
would get a 15002 error. >>

It's not really possible for a buffer overrun in the case of BLOB access.
Actually, I guess I should say that it is *possible*, but it would be a bug
that would crop up rather frequently if it were the case.  You would see all
sorts of hell breaking out on these newsgroups, and I would be leading the
charge since a lot of our internal systems still use DBISAM and heavily use
BLOBs, such as these newsgroups.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> There's a lot of access denied error messages for temporary tables in the
> server log.  Are they using AV software on the terminal server machine ?

The earlier Access Denied messages were due to permissions, which has since
been fixed. (I changed the temporary location on the server to a location
with full permissions). These happened a number of days previous.

Best Regards

Adam.

Tim,

See...I figured I might be way off base on this one.

Everything I have ever seen about problems with uncompressing buffers
always had to do with ZLib and almost always had to do with BLOBs or
large strings (of course they were usually associated with Unix too and
Adam isn't using that.)

--
Regards,
Jan Ferguson [Team Elevate]


Tim Young [Elevate Software] wrote:

<<It's not really possible for a buffer overrun in the case of BLOB
<<access. Actually, I guess I should say that it is possible, but it
<<would be a bug that would crop up rather frequently if it were the
<<case.  You would see all sorts of hell breaking out on these
<<newsgroups, and I would be leading the charge since a lot of our
<<internal systems still use DBISAM and heavily use BLOBs, such as
<<these newsgroups.

Hi Tim,

> << I might be way off base on this however when you are performing these
> queries, do you query any BLOB or memo fields for data? The reason I am
> asking is because in dealing with BLOB and Memo data types, I believe
> the database engine will allocate memory buffers for these and if your
> query will overrun those buffers, you might run into the situation where
> you would get a 15002 error. >>
>
> It's not really possible for a buffer overrun in the case of BLOB access.
> Actually, I guess I should say that it is *possible*, but it would be a
> bug that would crop up rather frequently if it were the case.  You would
> see all sorts of hell breaking out on these newsgroups, and I would be
> leading the charge since a lot of our internal systems still use DBISAM
> and heavily use BLOBs, such as these newsgroups.

Out of curiosity, is there anything we can do to 'trap' for this situation
just incase it is what's happening with my clients / application?

I mean - from what we can tell, the 15002 error is inaccurate because we're
not using compression at all, but obviously DBISam believes for some reason
we are. This being the case, is it possible that my application has some
rather unique structure (field layouts, indexes, who knows what) that is
causing this to raise this underlying bug when queries include memo's /
blobs and thus cause DBISam to raise this 'incorrect' error message?

I'm quite happy to do extra work to elminiate what might be almost
impossibilities, as this problem is beginning to get quite severe from my
end. Feel free to tell me what you'd like me to change in the source codes /
what traps to put in place, etc - and I'll be happy to do them!

Best Regards

Adam.

Adam,

<< Out of curiosity, is there anything we can do to 'trap' for this
situation just incase it is what's happening with my clients / application?

I mean - from what we can tell, the 15002 error is inaccurate because we're
not using compression at all, but obviously DBISam believes for some reason
we are. >>

Are you using compressed BLOBs with any tables ?

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:45B21C6A-AFBF-4DE7-89E5-7907D171E592@news.elevatesoft.com...
>
> I mean - from what we can tell, the 15002 error is inaccurate because
> we're not using compression at all, but obviously DBISam believes for some
> reason we are. >>
>
> Are you using compressed BLOBs with any tables ?
>

Earth to Tim...

Robert

Hi Tim,

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:45B21C6A-AFBF-4DE7-89E5-7907D171E592@news.elevatesoft.com...
> Adam,
>
> << Out of curiosity, is there anything we can do to 'trap' for this
> situation just incase it is what's happening with my clients /
> application?
>
> I mean - from what we can tell, the 15002 error is inaccurate because
> we're not using compression at all, but obviously DBISam believes for some
> reason we are. >>
>
> Are you using compressed BLOBs with any tables ?

The compression settings for these fields are set to NONE.  There are a
couple of tables in my database that have compression turned on for BLOB's,
but none that are referenced to in these queries.

Best Regards

Adam.

Robert,

<< Earth to Tim... >>

He meant with the remote sessions, not with the database tables.  See his
latest response.

--
Tim Young
Elevate Software
www.elevatesoft.com

Adam,

<< The compression settings for these fields are set to NONE.  There are a
couple of tables in my database that have compression turned on for BLOB's,
but none that are referenced to in these queries. >>

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

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.

--
Tim Young
Elevate Software
www.elevatesoft.com