Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 17 of 17 total |
Having Corrupt headers using 4.25 build 3 |
Thu, Feb 1 2007 7:16 AM | Permanent Link |
"Bern Rudisill" | Tim Young [Elevate Software] wrote:
> Robert, > > << Does the file date change? >> > > Good question. I was also going to ask if the LastUpdated timestamp > changes for the table in DBISAM. I will have to check both of these. I know the LastUpdated timestamp is changing because we are running a repair on the table. I will tell my support staff not to run a repair the next time but to copy the orginal tables instead so I can check this. -- |
Sat, Feb 3 2007 9:59 AM | Permanent Link |
"Bern Rudisill" | Bern Rudisill wrote:
> Tim Young [Elevate Software] wrote: > > > Robert, > > > > << Does the file date change? >> > > > > Good question. I was also going to ask if the LastUpdated timestamp > > changes for the table in DBISAM. > > I will have to check both of these. I know the LastUpdated timestamp > is changing because we are running a repair on the table. I will tell > my support staff not to run a repair the next time but to copy the > orginal tables instead so I can check this. I am putting the corrupt tables in public.binaires with a subject of corrupt mq_command table. Can you take a look and see what is corrupting. It seems we only have 1 customer that where the table keeps getting corrupt, all other customers are working find as of right now, the the corrupts they were getting were due to the largefile support no being turned on in all programs that access the DB. This one is really starting to bug me, and the customer is really starting to get ticked off, because when this table corrupts the app will not start. Even though I only read from this table and when the table is opened in my code I always set the read only property to true, it is getting corrupted. After putting a good copy of the table on their server (they are running in file-share mode) I also marked the table read only in the file system to see if maybe we could figure out what is going on. Thanks Bern -- |
Mon, Feb 5 2007 9:44 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Bern,
<< I am putting the corrupt tables in public.binaires with a subject of corrupt mq_command table. Can you take a look and see what is corrupting. >> Unfortunately having the tables doesn't do much good since it doesn't tell me what is causing the corruption. I am pretty sure, however, that there has got to be an issue with the LargeFileSupport settings. Did you try setting them all back to LargeFileSupport:=False and see if the corruption goes away ? -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Feb 5 2007 9:52 PM | Permanent Link |
"Bern Rudisill" | Tim Young [Elevate Software] wrote:
> Bern, > > << I am putting the corrupt tables in public.binaires with a subject > of corrupt mq_command table. Can you take a look and see what is > corrupting. >> > > Unfortunately having the tables doesn't do much good since it doesn't > tell me what is causing the corruption. I am pretty sure, however, > that there has got to be an issue with the LargeFileSupport settings. > Did you try setting them all back to LargeFileSupport:=False and see > if the corruption goes away ? Yes everything has LargeFileSupport:=false, all corrupt went away except for the mq_commands table. We only have one hospital where it keeps getting corrupted. I have doubled checked my code and this file is not being written to. Bern -- |
Tue, Feb 6 2007 6:43 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Bern,
<< Yes everything has LargeFileSupport:=false, all corrupt went away except for the mq_commands table. We only have one hospital where it keeps getting corrupted. I have doubled checked my code and this file is not being written to. >> It is basically impossible for a table to become corrupted if it isn't being written to. Is the machine hosting the table having issues with crashing, etc. ? -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Feb 6 2007 8:13 PM | Permanent Link |
"Bern Rudisill" | Tim Young [Elevate Software] wrote:
> Bern, > > << Yes everything has LargeFileSupport:=false, all corrupt went away > except for the mq_commands table. We only have one hospital where it > keeps getting corrupted. I have doubled checked my code and this file > is not being written to. >> > > It is basically impossible for a table to become corrupted if it > isn't being written to. Is the machine hosting the table having > issues with crashing, etc. ? Trust me I completely agree with you, for the life of me I can not figure out how a read only table is corrupting. As far as know there is not problem with the machine crashing or anything else. The last time the file crashed and I replaced it I also marked the files as read only in windows also, I am waiting to see if it corrupts again. Bern -- |
Thu, Feb 8 2007 12:15 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Bern,
<< Trust me I completely agree with you, for the life of me I can not figure out how a read only table is corrupting. As far as know there is not problem with the machine crashing or anything else. The last time the file crashed and I replaced it I also marked the files as read only in windows also, I am waiting to see if it corrupts again. >> That should do the trick. Nothing should be able to write to them now. -- 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 Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |