We no longer provide the DDT stand alone install as predominantly every one of our users were developers using the DDT over SQL administrators.  So it was axed since it was just one more installation to maintain.  As it sounds like you have already learned, it is very easy to create a .NET program to deploy your packages and is the "proper" way to deploy a database in the field   This is why we provided the Database Deployment sample...which you found...and made it your own

Just to explain a bit, the DDT stand alone install was NEVER designed with deployment in the field in mind.  That is why there is the DatabaseMigrator class.  If you think about it, this is exactly how we install the StrataFrame databases during an installation and this is how you should deploy to your customers.  That is why we provided the sample so you could see your options on how to do this.

Incidentally, the deployment dialogs within the DDT are included in the DBEngine.dll so you don't even have to write a UI... just a program that will call the MDDeployMain will get you there.

An install went bad, the application now has a "remembered" bad connections string, tries to use it and crashes when I try to run the app. It remembers the bad connection string even after I uninstall my application, where is this stored to I can delete it?

I am GREATLY missing the DDT Standalone install right now as all I can think to do is install VS,SF and deploy my package.

This thread has actually been a bit confusing to be to be honest.  The DDT was never designed to be placed at a clients site.  You are given all of the same tools, even the same deployment forms used within the DDT, within the framework and the database migrator class.  This is shown within the Database Deployment sample.

The reason I am confused is on this point.  If you are making changes to the end-users database outside of the same structure that is used to create your BOs, then your application and BOs are going to have to be recompiled in order to take advantage of the new structures.  So if you are doing this at a clients site, you would also need to re-run the BO Mapper and recompile to actually take advantage of changing the SQL structures on site.

To deploy the databases that you have created at design-time, this is the point of the PKG (package file) and the DatabaseMigrator class....and the sample that we have provided showing you how to use the pre-built forms or one of your own.

So I still do not see the need for the stand-alone install.  As mentioned above in Ben Chases post, you are going to have to setup the full StrataFrame database and re-import all meta-data in order for this to even be viable.  In other words, you have to re-create the same development environment at your clients site as your development site in order for this to even work.  So the ONLY reason would be to deploy a package, which you can create a stand-alone EXE or even use the same provided to create a facility to deploy PKG files outside of your application at a clients site.

There is nothing straight forward about re-creating your development environment at each of your clients site as mentioned above.  So I still do not see the need.  I think there is a misunderstanding as to what the stand-alone installation actually did before.