By Geoff Hirst - 7/7/2008
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
|
By Trent L. Taylor - 7/7/2008
We never let the end user have direct access to the PKG file for this very reason. In our medical software, we always remove the old PKG files and this is part of the install so they never have to manually select the PKG file (or shouldn't have to). But we leave it out there for support purposes in the case that we need to update their structures because they had other issues. The DDT actually does have a version that it updates when you change structures that was going to be used initially for other purposes. But it really doesn't get used at present and maybe this is something to consider in the future. The problem is that if a user selects the package file and no other package files are around...how do you check this? It would have to be on a database someplace. This is where we have landed everytime that we have thought about this and it would really be easier if this were checked within the deployment application instead. One approach may be to create a WinRar EXE that extracts the application and PKG file at the same time and executes it altogether and then cleans up after itself. Within this same EXE you could have a version file that you use to test a version table on your DB. There are a number of ways to probably create a test for this...but without having all of the PKG files in the same location, it would be difficult for the DatabaseMigrator class to determine this. I am open to suggestions if you have any in this regard...I could be missing a really simple solution 
|
By Geoff Hirst - 7/7/2008
Hi Trent,Thanks for the quick response. I could resort to holding the pkg file in the installer, keeps users hands off things. I found the version number while I was looking around, is there any way I can check this version of a selected package file, before it is actually deployed? I don't mind holding a variable or something in my application to check against. thanks Geoff.
|
By Trent L. Taylor - 7/7/2008
I found the version number while I was looking around, is there any way I can check this version of a selected package file, before it is actually deployed? 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.
|
By Geoff Hirst - 7/8/2008
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
|
By Edhy Rijo - 12/26/2009
Trent L. Taylor (07/07/2008)
I found the version number while I was looking around, is there any way I can check this version of a selected package file, before it is actually deployed? 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.
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!
|
By Edhy Rijo - 1/4/2010
Bump....
|
By Trent L. Taylor - 1/7/2010
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.
|
By Edhy Rijo - 1/7/2010
Trent L. Taylor (01/07/2010)
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.
|
By Trent L. Taylor - 1/7/2010
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.
|
By Edhy Rijo - 1/7/2010
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.
|
By Trent L. Taylor - 1/8/2010
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. 
|
By Edhy Rijo - 1/8/2010
Trent L. Taylor (01/08/2010)
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.
|