Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
To buy or not to buy?
Message
De
02/02/2006 11:51:19
Joel Leach
Memorial Business Systems, Inc.
Tennessie, États-Unis
 
 
À
31/01/2006 15:13:54
Information générale
Forum:
Visual FoxPro
Catégorie:
Stonefield
Versions des environnements
Visual FoxPro:
VFP 9
OS:
Windows XP SP1
Network:
Windows 2003 Server
Database:
Visual FoxPro
Divers
Thread ID:
01092041
Message ID:
01092926
Vues:
31
This message has been marked as a message which has helped to the initial question of the thread.
1) Stonefield fixes problems in the header, which is the most common cause of corruption. We use the Repair() function as an external utility, in case corruption prevents users from starting our app. I'm not sure table corruption can be detected "on-the-fly". Does someone know?

2) I didn't know that was a requirement, but I think what you suggested would work if the file structures are the same. We create the metadata locally and send it to all of our clients.

3) Custom utility when the update is performed. Automatic checks would work on a stand-alone installation, but I think would cause problems on a network where multiple users could start the application.

4) Yes.

5) I don't use xCase. If I did, I think I would still want SDT for the structure update capabilities and corruption fixes.

6) SDT fixes the most common problem in the file header. FoxFix and Abri Recover provide more sophisticated tools for fixing deeper corruption.

>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.
Joel Leach
Microsoft Certified Professional
Blog: http://www.joelleach.net
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform