Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 11 to 20 of 39 total |
DBISAM Engine Error # 15002 Error uncompressing data |
Wed, Mar 26 2008 7:16 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Wed, Mar 26 2008 7:20 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Wed, Mar 26 2008 6:27 PM | Permanent Link |
"Adam H." | 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. |
Wed, Mar 26 2008 10:39 PM | Permanent Link |
Jan Ferguson Data Software Solutions, Inc. Team Elevate | 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. |
Thu, Mar 27 2008 3:51 AM | Permanent Link |
"Adam H." | 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. |
Thu, Mar 27 2008 2:39 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 ? -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Mar 27 2008 4:55 PM | Permanent Link |
"Robert" | "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 |
Thu, Mar 27 2008 8:59 PM | Permanent Link |
"Adam H." | 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. |
Fri, Mar 28 2008 2:41 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Mar 28 2008 2:44 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
« Previous Page | Page 2 of 4 | Next Page » |
Jump to Page: 1 2 3 4 |
This web page was last updated on Friday, September 20, 2024 at 05:39 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |