Some of our customers add their own custom fields into the tables for reporting purposes, and also add custom tables for the same purpose. If we were to use the DDT to deploy the db, would it overwrite all custom tables/fields that the users put into their database? Is their any way to allow additions to the DDT deployed database structure to remain intact with each deployment?
Any new tables will be left alone. However, if they are adding new fields to a table that is deployed through the DDT, then these would be overwritten. They should be creating a user-defined function or view to do this anyway. In the 1.6.5 release, there will be some new changes that will leave any views, functions, and stored procedures not created through the DDT alone.
We have a few triggers in our db right now and plan to add more. Can the DDT handle these?
Triggers will be added in the next update...but the 1.6.5 release will have new support for user-defined functions which did not previously exist.
We may end up having to support other providers besides SQL. If this happens, we would need the ability to generate some sort of script to go between database versions (DDT packages) so that we could convert from SQL to another language (Oracle, DB2, etc). Is this possible at all? My real question here is can the DDT generate some sort of SQL script to run on a database which would bring it to the correct version.
The DDT will not support any database other than SQL Server. The next major version of the DDT may include some other database formats, but for now, it is a SQL Server only platform.