Guys,

My application makes use of the superb flexibility of the DDT. What I need to be able to do, is stop users importing 'old' pkg files. Is there a way to do this?

thanks in advance.

Geoff Hirst

Bump....

Edhy Rijo

The version number really serves no purpose, especially in regards to the DDT deployments as the DDT is intelligent and will determine what has changed. What problem are you trying to resolve here, Edhy?



A couple of thoughts. If you want there to be a version on the database, then use the Extended Properties of the database and set it through a Post Execution Profile. You can then query the Extended Property of the database prior to allowing a DDT PKG to be deployed there. This would be one solution. You would have to implement something like this anyway before the version in the PKG would have any meaning.



One more tip on this, use the file or assembly version of your application as the version on which you test and use this same value to update the extended property. This is a far more reliable solution.

Hi Trent,

Basically I am trying to automate the process of updating the database structure from the first workstation that launch the application.  I created a table in the database to hold the current DDT version and I want the application to check this version and compare it with the DDT PKG file and then update the database if needed.  My application target many customers which I will not have access to their database and need to automate this process of updating the database as much as possible with the less user intervension possible. 

I appreciate any tips in this regard.

Edhy Rijo

The simplest way would be to have a build version within your application that is referenced against the version in your table. Not the DDT package version. Straight up I am telling you that you are better off taking another approach to using the internal version of the DDT package. The advice I am giving you is what we do in certain scenarios. So create a Shared property within a class that has a custom version if you do not want to use the file or assembly version. Then take this version to update your table and check to see if there are any changes. This is a far more reliable and safer approach not to mention faster as no data extraction would be required.

Thanks Trent, will follow your advise and use a property to manage the database version.



The idea of using the version on the DDT was basically to keep things automated, since the DDT will automatically change the version when something changes in the package and that would be one left thing to remember, but if you guys will not make this version information available at runtime and if it would be needed to uncompress the file package to get the version then it may not be worth the overhead, a property will do the trick.

Edhy Rijo

Keep in mind that you can setup a file or assembly version to automatically change each time you compile with an "*" in the build and revision slots. This way you can still forget about it versus always having to remember.

Thanks, I did not know that.

Edhy Rijo