Thanks, I did not know that.

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 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

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.

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 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.

Bump....

Edhy Rijo

Hi Trent,



I am starting to use the DatabaseMigrator class to automate the update process and have the need for such a method to read the version number of the DDT package. Have you been able to implement this or at least could you provide the VB.NET code to get this information from the DDT package file so we can use it until it gets implemented in the SF code?



Thanks!

Edhy Rijo

Trent,

That would be excellent. I hope this is possible to add. For it would allow an audit trail be created that would show the database updates applied and when. In addition, when one is applied, it would be possible to keep a record of it and display the 'database version' in an about box.

I am presently migrating over to making the db update process part of the installation, like you mentioned you do with your medical application. This will obviously reduce the issue, but it would still be nice to be able to access the database version.

thanks in advance.

Geoff Hirst

Yeah....this is basically some residue from the initial release of the DDT that we left in for the intent that we may try to use it for this very purpose.  At present the answer is, "no."  But this is something that could be added very easily and we could have a method in the DatabaseMigrator class that accepts a package file path and then returns back the version.  That could be useful.