>>>I have heard that it is not wise to pack a table on a production system, especially when you're dealing with a fairly large table. ( 100,000+ ). Instead you do something like:
>>>
>>>PARAMETERS tcDbc, tcTableName
>>>USE (tcTableName)
>>>COPY TO TEMP DATABASE (tcDbc) FOR NOT DELETED()
>>>RENAME TEMP.DBF TO &tcTableName..DBF
>>>REINDEX
>>>* Or recreate the indexes one by one from a data dictionary
>>>
>>>1. Is the correct syntax.
>>>
>>>2. If its correct, is there a problem in VFP 5, where the copy to only copies the first 10 characters of field names.
>>>
>>
>>There are a large number of issues with this method of packing tables that are a part of a database container and rebuilkding indexes using this method. Do yourself a tremendous favor, and purchase a copy of SDT (Stonefield Database Toolkit) from Stonefield; they're UT Partners, and offer a discount to PUTM purchasers. SDT provides mechanisms that can pack/reindex/reconstruct/update/fix tables both in a DBC and free-tables; it provides significant extensions to the DBC capabilities through a public metadata extension system called DBCX. The singnifcantly enhanced PACK, REINDEX and additional capabilities can be incorporated into your application and distributed on a roylty-free basis with your applications. It's paid for itself many times over for me.
>
>
>I've heard its quite an ordeal to setup SDT for a project. Is that true? You didn't mention RI. Is that taken care of as well?
>
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.
>Dan
