Yes, technically, you could install the DDT on the client's site and then deactivate before you left the site... you can only have one install currently activated for a each license you have.

I am onsite at a customer right now having a major issue.

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?

Keith Chisarik

I found how to delete them, the problem now is that my app wont run far enough to run the DDT install methods since it is looking for SF "stuff" in the database that hasnt been deployed yet.

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.

Keith Chisarik

Hrm... yes the DDT requires access to the SF database or it will crash as soon as it starts up.  The standalone DDT install would be the same way; it would also require the StrataFrame database, too.  You'll have to either create a standalone app that uses the MDDeployMain to deploy the data or open up 1433 to your SQL Server so that you can reach it to open the DDT.

Ben, isn't it better that we just buy a copy of a stand alone DDT and put it on client machine? Can we then get us a stand alone installation, so it will become a straight forward installation?



Thanks!

..ßen

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.

Hi Trent;



I had gone back and looked deeper into this and you're right. Sometime, when we come from other systems, we tend to think in the old fashion way (when I'm in TX, I'll show you how we used to have a DDT "Type" program at the design site and one at client site).



But it's good you make clarifications to these posts, so new users see the points already discussed!



Thanks!

..ßen