Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 11 to 15 of 15 total |
Index Page Buffers Corrupt |
Tue, Mar 7 2006 3:15 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< How long have you been aware of this. In conversation previously when I was asked why we were still on 3.21, I said because it was stable, and no mention was made that Index Page Buffers could be an issue. >> It was found in version 4.x long after 3.x was frozen. Also, what previous conversation are you referring to ? << This seems fairly serious especially since a rebuild seems to delete actual data on ccasion. Anyway we are desperate for this new dbisamem.pas unit to fix this critical issue. Our prgrammer is going on leave soon and we need to resolve. >> It was sent to you earlier this afternoon (EST). << Also are there any other potential issues you are aware of in a high volume environment? >> No. But you also have to realize that we haven't touched 3.x in at least a year, and we don't go back and re-test 4.x bugs against 3.x to see if it would be affected. This is why we are so adamant about people upgrading to the latest major version in a reasonable time frame. We simply don't have the resources to do active development on multiple major versions for long periods of time. 3.x was even longer than normal in that we issued 3.x updates for quite a while after 4.x was released. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Mar 7 2006 3:36 PM | Permanent Link |
Kevin Kozlowski | Tim,
<< No. But you also have to realize that we haven't touched 3.x in at least a year, and we don't go back and re-test 4.x bugs against 3.x to see if it would be affected. This is why we are so adamant about people upgrading to the latest major version in a reasonable time frame. We simply don't have the resources to do active development on multiple major versions for long periods of time. 3.x was even longer than normal in that we issued 3.x updates for quite a while after 4.x was released. >> Could you also send this to me? We have a medium sized application running in v3.30 that we were going to move to v4.x, but then heard that v5.x was on the way. We have the same issue as you in terms of resources. It would take quite an effort to QA all the SQL scripts (a couple of months) to make sure they work properly under v4.x. Can you give some guidance on the v5.x schedule? If it is still 3 to 6 months off, then we probably need to move our app to v4.x as we just couldn't afford a corruption issue like the one describe in this thread out in the field. On the other hand, if v5.x is targeted for release (or preview so we could start porting) in the next 1 - 2 months, then this would really help out a shop like ours where we are tight on resources I'd appreciate whatever information you are willing to share. Either way, I'd like the v3.30 source file that you provided to others on this thread. Thanks, -Kevin |
Wed, Mar 8 2006 12:17 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Kevin,
<< Could you also send this to me? >> Sure. Just send me an email (timyoung@elevatesoft.com) and I'll reply with the source file. << We have a medium sized application running in v3.30 that we were going to move to v4.x, but then heard that v5.x was on the way. We have the same issue as you in terms of resources. It would take quite an effort to QA all the SQL scripts (a couple of months) to make sure they work properly under v4.x. >> The only difference of any significance between 3.x and 4.x in terms of SQL INSERT/UPDATE/DELETE/SELECT is the single-quote/double-quote issue with constants and the change of the MEMORY keyword to the "Memory" database name. Any other changes were fixes that 3.x was performing incorrectly, or where minor changes to the CREATE TABLE/ALTER TABLE table creation/alteration. << Can you give some guidance on the v5.x schedule? If it is still 3 to 6 months off, then we probably need to move our app to v4.x as we just couldn't afford a corruption issue like the one describe in this thread out in the field. >> It's not 6 months off, but it is still at least a month or so off. February and March so far have not been very productive in terms of development time. Unfortunately that's simply one of the bad sides of having limited development resources. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Mar 9 2006 12:50 AM | Permanent Link |
"Al VAs" | Hi Tim,
Believe me I realise what limited resources means. Like the gentleman Kevin said, it takes a great effort to move from V3 to V4 even if it is just as you say, quotes, as we have many SQL statements and reports that would need to be changed and fully tested to ensure nothing is broken. I have also been waiting for Version 5. My previous conversation was only recent (we moved to 3.3 from 3.21 only a couple of weeks ago, and no mention was made of this serious bug, I am aware that it could slip the mind and Joe couldnt find anything describing that particular issue. So I was just asking. Thanks Alex "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:5282549E-C7C2-4AC6-9493-9CB6563B4F77@news.elevatesoft.com... > Alex, > > << How long have you been aware of this. In conversation previously when > I was asked why we were still on 3.21, I said because it was stable, and > no mention was made that Index Page Buffers could be an issue. >> > > It was found in version 4.x long after 3.x was frozen. Also, what > previous conversation are you referring to ? > > << This seems fairly serious especially since a rebuild seems to delete > actual data on ccasion. Anyway we are desperate for this new dbisamem.pas > unit to fix this critical issue. Our prgrammer is going on leave soon and > we need to resolve. >> > > It was sent to you earlier this afternoon (EST). > > << Also are there any other potential issues you are aware of in a high > volume environment? >> > > No. But you also have to realize that we haven't touched 3.x in at least > a year, and we don't go back and re-test 4.x bugs against 3.x to see if it > would be affected. This is why we are so adamant about people upgrading > to the latest major version in a reasonable time frame. We simply don't > have the resources to do active development on multiple major versions for > long periods of time. 3.x was even longer than normal in that we issued > 3.x updates for quite a while after 4.x was released. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > > |
Thu, Mar 9 2006 3:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< Believe me I realise what limited resources means. Like the gentleman Kevin said, it takes a great effort to move from V3 to V4 even if it is just as you say, quotes, as we have many SQL statements and reports that would need to be changed and fully tested to ensure nothing is broken. I have also been waiting for Version 5. >> I understand. However, the changes going forward are always towards greater compatibility with ANSI standard SQL, not less, so you can take comfort in the fact that we will be standards-compliant with version 5 in terms of any SQL that we support. That will ensure that future changes to the SQL will only change if the standards change, which they rarely do in the key areas. << My previous conversation was only recent (we moved to 3.3 from 3.21 only a couple of weeks ago, and no mention was made of this serious bug, I am aware that it could slip the mind and Joe couldnt find anything describing that particular issue. So I was just asking. >> My apologies for not catching your comment about moving from 3.30. The issue was in 3.x for some time apparently and I haven't gone back to compare the sources to find out exactly when, so I sometimes make the mistake of assuming that if you're using 3.x, then you probably already encountered the problem if it was a problem. It's actually quite rare, actually. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 5, 2024 at 07:30 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |