My company is evaluating the Stonefield database toolkit, and while the results have been positive, it seems that since we have been getting along for years without the tool, I need some extra justification to spend the $350 per developer. Any responses to the following questions would be helpful.

1) We don't experience much table corruption, but as we transition to more databases vs. free tables, we are encountering more instances of corruption, epecially of the error 2091 variety. Has Stonefield resolved most of your table corruption issues? Are your applications repairing tables on the fly, or are you manually using the repair() function? It seems like a good idea to automatically repair, but perhaps problems occur when multiple apps detect the same problem and each try to repair the problem.

2) My understanding is that the metadata must exist prior to table corruption, otherwise stonefield has no basis for the repair function. While this sounds logical, it doesn't help us when we have tables that haven't been setup with metdata. Is it possible to take a good copy of the table (but having different data) create the metadata, and use that to repair the corrupted table?

3) What are you using for the update mechanism? Custom update utilities built around SDT? Automatic checks at the start of the program?


4) It seems like I am able to update databases & tables that are actively being used, but I did run into problems. Is it best to make sure all users are out of the program before running the update method?


5) There is some feature overlap between xCase & stonefield. Are they close enough where people use one or the other or are they used more as complementary tools?


6) Any recommendations for a supplementary repair tool?


Thanks,

Brian Vander Plaats
Vogel Paint, Inc.