Hi,

I´m using DatabaseMigrator to deploy DB changes to a lot customers databases in the same server.
The problem is:
All commands are processed every time that I run the program, but I realized that it rans the same command already proccessed before like:

• 12/03/2010 09:56:02 -> The relationship 'FK_tb_ped_compra_tb_item_pec' was created successfully.
• 12/03/2010 09:56:09 -> The relationship 'FK_tb_tit_pag_tb_tit_pag_ccusto' was created successfully.
• 12/03/2010 09:56:09 -> The relationship 'FK_tb_tit_pag_tb_tit_pag_proj' was created successfully.
• 12/03/2010 09:52:50 -> The table 'tb_tit_rec' was successfully altered.

Other thing:

• 12/03/2010 09:52:42 -> The relationship 'FK_tb_tit_rec_tb_tit_rec_ccusto' was successfully dropped.

If DatabaseMigrator drop my FKs, what is happen if I run it over a DB with real data?

Tks guys

I don't understand what you are getting at here. The DatabaseMigrator inspects any tables upon deployment and may drop foreign key contraints so that the table can be updated. In many cases, if this is not done, columns, indexes, etc may not be created due to the contraints.



So in short, I am not sure what your question/issue is. You say that the DBM always reruns a whole command, but I don't really know what you are mean. The DBM does inspect the entire database, as it should. And at times, it may have to drop and recreate indexes and constraints as required by SMO.

Trent,

For example:
>>>>12/03/2010 09:52:50 -> The table 'tb_tit_rec' was successfully altered

I did a change in table tb_tit_rec in last month (I changed the field size) , DBM showed this message today.
Strange because the field size is corrected, I´m trying to understand how DDT works.

Tks

 

Well, without getting your deployed database, your package, understanding all of your structures, then debugging the deployment process, I cannot give you a straight answer. There was something within the DBM that thought this needed to be updated. This is sometimes like asking, "How long is a string." It is difficult to give a straight answer without having 100% of the facts. Sorry.

Trent,

No matter....  100% perfection is "Wizard of OZ..."!
DDT is a really cool tool, I´m going using it with this way.

There´s a deadline to new version?
My worry today is about the time to updating more than 100 databases.....

Tks

Well, the DDT will be getting a lot of fun new features, but these will just enhance the software. What feature are you waiting for? We use the DDT daily and have thousands of installations. It works and we rely on it daily.

Trent,

DDT is almost perfect, before it I tested and used this solution:

http://www.xsqlsoftware.com/Product/Sql_Schema_Compare.aspx

DDT is so different than other solutions, but I thought basically in a save snapshot concept, for example:

- Day 23 I include a field, the DDT knows the version of DB a proccess only ALTER TABLE ADD XYZ.

http://www.xsqlsoftware.com/Product/xSQL_Database_Version_Control.aspx

My main problem is the time consumption for DDT deploying in a same server, I have 100 tables and DBM spend 3 minutes per database.

Ok... It´s !!!!

See ya....

Thanks for your input Luiz.  The DDT is a very complex tool and does a lot.  Providing the ability to avoid scripts as well as move from version 1 to 10 in a single step requires some testing and configurations.  However, I do receive your input and one of the things high on our list is a new version of the DDT.  I agree that there are times when speed is an absolute.  I am not sure why it is taking 3 minutes as our medical app has over 200 tables, hundreds of sprocs, dozens of views, CLR assemblies, and plenty of UDFs and it doesn't take 3 minutes (unless running in a porr environment which can happen from time to time).  All of that being said, there is always room for improvement and learning from current versions...that is why there is always a next version!   Thanks for your business and input.

Trent..

Ok.. fantastic.. I will do more tests to reduce the time and I will wait for next version of DDT!

See ya