Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 10 of 12 total |
C/S and index errors |
Thu, Nov 29 2007 12:55 AM | Permanent Link |
"Al Vas" | Hi,
I just want to revisit this. We have a number of clients who use one of our products. All of them run in client/server mode and it is quite a high volume function in terms of records created. More than I like, we have index mismatches which require a rebuild of the table. It is usually, but not always, the table that is accessed the most frequently by many users. Is it probable that our own coding is causing this in some way? As far as I understand in client/server there is very little, other than a server shutdown, or abnormal database engine shutdown that would cause an index error. If it is potentially coding, what should we be looking for? Thanks Alex |
Thu, Nov 29 2007 3:18 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Al
What version and what's the structure of the table? Are there memo fields being updated? Roy Lambert |
Thu, Nov 29 2007 4:14 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< I just want to revisit this. We have a number of clients who use one of our products. All of them run in client/server mode and it is quite a high volume function in terms of records created. More than I like, we have index mismatches which require a rebuild of the table. It is usually, but not always, the table that is accessed the most frequently by many users. Is it probable that our own coding is causing this in some way? As far as I understand in client/server there is very little, other than a server shutdown, or abnormal database engine shutdown that would cause an index error. If it is potentially coding, what should we be looking for? >> Is this 3.x ? If so, then I would suggest that you upgrade your customers to 4.x at the very least. 3.x simply is not going to have any more fixes, so there isn't much I can do to help you. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Nov 29 2007 8:01 PM | Permanent Link |
"Al Vas" | Hi Roy,
It is V3.30. Many tables do include memo fields. The highly used table has 1 memo field and 14 secondary indexes Alex "Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message news:48944BF9-E209-476D-8E0F-98B0A5D7522A@news.elevatesoft.com... > Al > > > What version and what's the structure of the table? Are there memo fields > being updated? > > Roy Lambert > |
Thu, Nov 29 2007 8:05 PM | Permanent Link |
"Al Vas" | Hi Tim,
Yes unfortunately we just havent had the window of opportunity amongst alot of development to upgrade to 4. Based on our previous experience of moving from 1 to 2 and 2 to 3 we know there is alot of work and testing and updating of tools that we have. I wasn't really asking for fixes to 3.x but would be appreciative if there is any knowledge out there of any issues that would cause these index problems. If it is our code, I'm just interested on what sort of coding would cause index issues as we don't do anything tricky when it comes to table access. Alex "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:A74ABC97-6971-4518-B96C-65D770B3B1DA@news.elevatesoft.com... > Alex, > > << I just want to revisit this. We have a number of clients who use one > of our products. All of them run in client/server mode and it is quite a > high volume function in terms of records created. More than I like, we > have index mismatches which require a rebuild of the table. It is > usually, but not always, the table that is accessed the most frequently by > many users. > > Is it probable that our own coding is causing this in some way? As far as > I understand in client/server there is very little, other than a server > shutdown, or abnormal database engine shutdown that would cause an index > error. If it is potentially coding, what should we be looking for? >> > > Is this 3.x ? If so, then I would suggest that you upgrade your customers > to 4.x at the very least. 3.x simply is not going to have any more fixes, > so there isn't much I can do to help you. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > |
Thu, Nov 29 2007 10:31 PM | Permanent Link |
"Robert" | "Al Vas" <forgetit@forgetit.com> wrote in message news:785F1627-08D0-4E59-B517-D3F6C3AA9150@news.elevatesoft.com... > Hi Tim, > > Yes unfortunately we just havent had the window of opportunity amongst > alot of development to upgrade to 4. Based on our previous experience of > moving from 1 to 2 and 2 to 3 we know there is alot of work and testing > and updating of tools that we have. I wasn't really asking for fixes to > 3.x but would be appreciative if there is any knowledge out there of any > issues that would cause these index problems. If it is our code, I'm just > interested on what sort of coding would cause index issues as we don't do > anything tricky when it comes to table access. > There was a bug in 3.30 that was eating my lunch, corrupting indexes on tables that had a lot of multi-user activity, finally decided to upgrade o V4. You are right that the upgrade is not trivial, especially if you use a lot of SQL. If you have the V3 source, I think Tim has the fix that you can apply. Robert |
Fri, Nov 30 2007 3:16 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Al
In my case it was a combination of threads (much the same as multiple users) and full text indexing that I think caused the problem. It was eventually sorted when I was able to produce a test case. I can't remember the version though. Roy Lambert |
Fri, Nov 30 2007 2:57 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Alex,
<< Yes unfortunately we just havent had the window of opportunity amongst alot of development to upgrade to 4. Based on our previous experience of moving from 1 to 2 and 2 to 3 we know there is alot of work and testing and updating of tools that we have. I wasn't really asking for fixes to 3.x but would be appreciative if there is any knowledge out there of any issues that would cause these index problems. If it is our code, I'm just interested on what sort of coding would cause index issues as we don't do anything tricky when it comes to table access. >> Yes, but you have to remember that the last time I even touched 3.x was years ago. I really can't even remember anything relevant to the discussion anymore at this point. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Dec 1 2007 3:53 AM | Permanent Link |
"Al Vas" | Fair enough Tim. I guess though, if index issues are caused by our code,
then it will be no different if we upgrade to 4, so it might be wise for us to start investigating before we move to 4.? Has anyone had experiences with indexing issues caused by their code in Version 4? Regards Alex "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:BD05B7F8-3B15-420F-9C35-F868044A5AE3@news.elevatesoft.com... > Alex, > > << Yes unfortunately we just havent had the window of opportunity amongst > alot of development to upgrade to 4. Based on our previous experience of > moving from 1 to 2 and 2 to 3 we know there is alot of work and testing > and > updating of tools that we have. I wasn't really asking for fixes to 3.x > but would be appreciative if there is any knowledge out there of any > issues that would cause these index problems. If it is our code, I'm just > interested on > what sort of coding would cause index issues as we don't do anything > tricky when it comes to table access. >> > > Yes, but you have to remember that the last time I even touched 3.x was > years ago. I really can't even remember anything relevant to the > discussion anymore at this point. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > |
Sat, Dec 1 2007 12:24 PM | Permanent Link |
Eryk Bottomley | Al,
> Fair enough Tim. I guess though, if index issues are caused by our code, > then it will be no different if we upgrade to 4, No, because the only way that your code could cause index corruption would be if you added code to the server which caused a catastrophic failure of the entire process (and I suspect you would know if that were happening). Client side code could only cause index corruption if it managed to unearth an otherwise unknown bug in the V3.x engine and it is unlikely that such a bug would have managed to persist through the entire product lifetimes of V3.x AND V4.x undetected. > to start investigating before we move to 4.? Has anyone had experiences > with indexing issues caused by their code in Version 4? Only server side code causing the process to AV and die unexpectedly. Eryk |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |