By ChanKK - 2/2/2009
Hi,Pls refer to the following errors that I got when I deploy a package to SQL Server using Database Deployment Wizard. These errors only occured when I run the wizard for the 2nd time but it works fine for the 1st time without any error. Senarioes 1. The database already exist at SQL Server(eg:VfsMain) and I run the wizard for the 2nd time using the same package but I renamed the Database Name on Server to another name(eg:VfsMain2). I hit this error as per attached (FlexHRDatabase_results4.rtf). 2. The database already exist at SQL Server and I run the wizard again for the 2nd time using the same package. I hit this error as per attached (FlexHRDatabase_results1.rtf). Pls kindly advice.Thanks.
|
By Chan - 2/3/2009
Hi,
>>Chan and Visual Solutions are in the same company
To add-on, the problem occurred only if we added default data package for Localization tables. Else, it works fine. Any ideas?
URGENT help needed!
Thank you
|
By Greg McGuffey - 2/3/2009
I think the problem is that you didn't parameterize your file names and the second run is trying to recreate files with the same names as those already created and in use from the first deployment. I believe you have to use the $DbName$ parameter in the file group area, within the file name, so this doesn't happen. It's been a while since I set this up, so check out help for the exact parameter name usage.
|
By Trent L. Taylor - 2/3/2009
Greg has a good point. if the problem persists, then the only way to realy diagnose things like this is for you to supply a backup of the database to which you are deploying and the PKG you are distributing to the DB so that we can reproduce the problem. Additionally, please add steps to reproduce the issue. Thanks.
|
By Chan - 2/3/2009
Hi,
Do you meant that I can't just import database everytime when I want to deploy?
I am not using DDT to maintain my database structure. Instead, we would like to use database diagramming tool such as xcase to design our database. Then generate the latest database. After that, using DDT to import the latest database strcuture for deployment.
Please advice. Thank you
|
By Greg McGuffey - 2/3/2009
I think that if you do this, you would need to modify the file options to use the $dbName$ parameter, so you can deploy to a differently named db, with unique file names, thus install more than once on any given server.
|
By Chan - 2/3/2009
Hi,
Thank you. We will test on that.
What about the 2nd issue?
Thank you
|
By Greg McGuffey - 2/4/2009
Do you mean about using some other tool to actually manage db structure changes, like the xcase tool, then use DDT to manage deployment?
I'm not sure this will work.  I think the problem would be that the way DDT manages the deployment is by tracking all the changes you've made to the structure over time. It then can use this history to figure out what needs to be done to update any older version of the database to the current version. Without the history, I think this would either simply blow away the old database/objects within the database (not good) or fail because there are existing items within the database that the DDT isn't managing that have the same name (DDT adds extended properties to any object is manages).
So, I think the question is, can you use importing to update the structure within DDT in a way that would update the history of changes made. I.e. if you have a Customers table with two columns cust_pk and cust_name, then use xcase to add a third column, cust_city, if you import the resulting db back into DDT, will it have a history item indicating that a new column was added? I think you could run a test to figure this out, as you can view the history for a DDT project.
Even if this works, I think you would have to be careful in certain situations, like renaming columns. I.e. if you have a column named cust_zip, then realize that you need to use a non-US name for it and change it to cust_postalcode, the import would likely interpret this as deleting the cust_zip and adding a new column cust_postalcode, which would blow away any data during the upgrade. If this had been done in DDT, it would have known that a rename occurred and there would be no problem. Using an external tool, you likely have to to manage this via the pre script to rename the column yourself before running the DDT script (assuming this would work at all).
I use DDT to manage my security db, as it is just way too easy to keep the SF security tables updated via this method. However, my primary application db is not managed via DDT. I use a text editor to write the SQL scripts (kinda scary). I then use a tool called DbGhost to manage the deployment. It has the same issues you'd have with things like renaming columns or tables and it allows pre/post scripts. It can also manage synching data (like data in lookup tables). It isn't as nice as DDT in the sense that if you manage your structure within DDT, it will handle more db changes. However, I really like being able to check in my SQL script into source control and run diffs on them. Also, when I made this decision, the DDT didn't import sprocs or functions or maybe even triggers and it didn't use extended properties to allow non-DDT managed objects to coexist in the same database. I already had all the script, so it made sense to use another tool.
Hope that helped!
|
By Chan - 2/4/2009
Hi,
Thank you for you valuable information.
If so, I might need to keep all history, then it would be very very huge in future. Beside, it could be confused as developers might do something wrong in DDT and revert them back and etc. If all of this stored in history, it might cause unexpected problem, would it?
I was thinking DDT would compare customer db and generate the upgrade script on the fly during upgrade based on the package generated. Shall SF team confirm on this? I know RedGate has a utility for this, but it required us to restore our latest db in order to work which is not our preference. Shipping XML/package is the way.
Please advice. Urgent!
Thank you
|
By Chan - 2/4/2009
Hi Greg McGuffey,
FYI, xcase able to track field renamed and generate the right script. I am not sure how it works.
The downside is, xcase doesn't provide developer tool for this purpose. 
|
By Greg McGuffey - 2/4/2009
I'll be interested in what the SF team has to say about how this might work (using an external tool, then using DDT to manage deployment) and your question about the history. I'm kind of at the end of my knowledge here (OK, maybe a bit beyond that  ) as I primarily use DbGhost and scripts.
|
By Chan - 2/4/2009
Hi,
For 2nd issue, error while deploy data. I have attached my package, DDT log and step to reproduce.
Please advice ASAP.
Database Deployment Toolkit
1.Import two databases, VfsLocalization and VfsSecurity.
2.Created deployment data for tables,MessageItems & MessageLanguages from VfsLocalization and deployment data for tables,SFSPreferences & SFSPreferencesChild from VfsSecurity.
3.Create package.
Database Deployment Wizard
1.Run and select the package that I have created.
2.Complete the whole process for the 1st time,everything runs smoothly.
3.Run and select the package for the 2nd time using the wizard.
3.The whole process completed with errors.Pls refer to attachment(Test_results1.rtf)
Thank you
|
|