>Not really - in fact, most commercial frameworks include hooks for its use, and adding SDT's functionality to an app involves creating a couple of objects and making them available globally, through an app object, or by attaching them to another globally visible object like _SCREEN. Your existing code does not need to pay any atttention to SDT unless you choose to use its capabilities to extend the DBC via DBCX; once you've created the objects and ensured that the proper metadata tables which were built for you by SDT's developer tools are accessible, you can call the SDT methods for packing/reindexing rather than the native pack and reindex commands, with as much or as little visibility and user control as you feel a need to grant. Doug Hennig has done a great job of documenting the product and explaining how to use it.
>
>If you feel you'd rather roll your own because you can do it better/cheaper/faster, fine. Like I said, I've saved tons of money and lots of mental anguish with it. I couldn't come close to duplicating the functionality for anywhere near what it cost, and I'd already had a running start on things when I bought it. It's probably the single best VFP add-on I've purchased, and using it has become second nature at this point.
>
>SDT handles RI however you hadle RI within your DBC - it will update any stored procedures in the DBC, including RI triggers, as a part of its update functionality.
>
Excellent, thanks for the info.