>>>But SDT doesn't recover for you ALL the things in a DBC.
>>
>>Such as? It's possible that you're correct; I haven't had to send out a .DBC with an app that I've developed since I started using the product; instead, I simply send out updated .DBC metadata and let SDT at the customer site do all the work. I've updated tables, views, indexes, stored procedures including default and non-default RI using it. Connections are built on-site, simply because I don't have the deployment details back at my office, but they're done by creating records that I merge into the metadata at the customer site. And with 5.1, it also handles many of the details of free tables and the like.
>
>Hum? Don't know exactly what SDT is doing from inside, but from days age I've been looking at the DBCX2 model, and there is no data nor fields, for things like the field caption, ri, stored procedures... if SDT uses only dbcxreg and coremeta there is not such data, if it works for you maybe SDT extracts this stuff from the DBC, and trusts in some DBC data (not me! if the DBC would be corrupted)
>
>Sorry, I only have the demo version and can't test this.

While it stores its metadata in DBCX-formated files to extend the DBC functionality, it fully extracts all descriptors needed to create fields, tables etc and stores them in DBCX-created and maintained metadata; it's miles beyond what the free DBCX extensions do. Like I said, I haven't had to ship a .DBC with an app since I started using it. It has no reliance on the DBC - it can (and does a beautiful job of doing this) create a .DBC from scratch at the customer site and you'll never have the headaches associated with building a .DBC or any of its components from scratch - you can send out the metadata files and it will build -everything- including the tables and indexes in place as directed without ever having had them in place before on site. And since it builds everything in the target environment, no messy fixups for bad data locations, and when it does fix things after moving them, the entries in the DBC are updated correctly. The only thing it can't hold is data that should be in the tqable like predefined values, and those can be sent out and imported IAC, and the DBC isn't involved in that issue.

If you haven't tried it, you are seriously working too hard and probably don't have maintenance and recovery tools with anywhere near the power and reliability that SDT offers. YMMV.