Support Forums - View Thread

View Thread

The following is the text of the current message along with any replies.

Messages 1 to 7 of 7 total

Fri, Jun 25 2010 5:44 PM	Permanent Link
Ken M Microlynx Systems Ltd.	Is there any downside with calling RepairTable on a table that may not have any problems? In my application I have a large number of tables with many records in each. I'd rather not incur the overhead of calling VerifyTable and then possibly RepairTable. Thank in advance for any thoughts, Ken M
Fri, Jun 25 2010 6:12 PM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Ken, << Is there any downside with calling RepairTable on a table that may not have any problems? In my application I have a large number of tables with many records in each. I'd rather not incur the overhead of calling VerifyTable and then possibly RepairTable. >> Both require exclusive access to the table, so no, there really is no downside. -- Tim Young Elevate Software www.elevatesoft.com
Fri, Jun 25 2010 7:39 PM	Permanent Link
Ken M Microlynx Systems Ltd.	Thanks Tim "Tim Young [Elevate Software]" wrote: Ken, << Is there any downside with calling RepairTable on a table that may not have any problems? In my application I have a large number of tables with many records in each. I'd rather not incur the overhead of calling VerifyTable and then possibly RepairTable. >> Both require exclusive access to the table, so no, there really is no downside. -- Tim Young Elevate Software www.elevatesoft.com
Sun, Jun 27 2010 12:03 AM	Permanent Link
Gerald J. Clancy, Jr.	Correct me if I'm wrong, Tim, but if there likely isn't any trouble with the table, Verify will go much faster that Repair, will it not? Jerry "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:B8C7F325-F05C-4302-947D-37AFBE679F53@news.elevatesoft.com... > Ken, > > << Is there any downside with calling RepairTable on a table that may not > have any problems? In my application I have a large number of tables with > many records in each. I'd rather not incur the overhead of calling > VerifyTable and then possibly RepairTable. >> > > Both require exclusive access to the table, so no, there really is no > downside. > > -- > Tim Young > Elevate Software > www.elevatesoft.com
Mon, Jun 28 2010 11:48 AM	Permanent Link
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com	Jerry, << Correct me if I'm wrong, Tim, but if there likely isn't any trouble with the table, Verify will go much faster that Repair, will it not? >> No, they both use the same code, with the only difference being that the repair will actually go through the process of repairing any damage that it detects. I'm working on some improvements to the repair for ElevateDB, one of which is the ability to run Verify without exclusive access. When I get that running, I'll see about back-porting it to DBISAM since it will then make a verify be much more useful since it can then be run on open tables. It will block any writes while it runs, but it is usually pretty fast, so it should be usable. -- Tim Young Elevate Software www.elevatesoft.com
Sun, Jul 11 2010 11:45 PM	Permanent Link
Gerald J. Clancy, Jr.	Sorry for the late response but I've taken a few days vacation. Thanks for the clarification and the proposed improvements. Running in non-exclusive mode would be a huge plus and allow more routine verify runs. Jerry "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:708C612F-19A9-479C-9F4D-0BEBF3C604E2@news.elevatesoft.com... > Jerry, > > << Correct me if I'm wrong, Tim, but if there likely isn't any trouble > with the table, Verify will go much faster that Repair, will it not? >> > > No, they both use the same code, with the only difference being that the > repair will actually go through the process of repairing any damage that > it detects. > > I'm working on some improvements to the repair for ElevateDB, one of which > is the ability to run Verify without exclusive access. When I get that > running, I'll see about back-porting it to DBISAM since it will then make > a verify be much more useful since it can then be run on open tables. It > will block any writes while it runs, but it is usually pretty fast, so it > should be usable. > > -- > Tim Young > Elevate Software > www.elevatesoft.com
Tue, Dec 30 2014 5:57 AM	Permanent Link
Johny Profiles	Ken M wrote: Is there any downside with calling RepairTable on a table that may not have any problems? In my application I have a large number of tables with many records in each. I'd rather not incur the overhead of calling VerifyTable and then possibly RepairTable. Thank in advance for any thoughts, Ken M Performance might be your only concern.