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

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.

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

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.

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

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

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.

License are "per developer" though right?



If I decide I want to deactivate my license on my desktop to take DDT to a client site (or install to a "developer box" on site, that is OK right, so long I I deactivate when I am done?



My thought of a developer license is that so long as it is me doing it, I can do what I want, where I want?



You licensing model really doesn't allow for any exploit, but I still like to do things "by the book" if I have misinterpreted anything, please let me know.








Keith Chisarik

Sorry if I misspoke Keith... I thought your deployment scenario was that you were going to have the DDT installed on your computer and with remote access to the SQL Servers through TCP 1433 you would deploy from your DDT to their SQL Servers.  Each install of the DDT takes a license.  You can deploy through the MicroFour StrataFrame DBEngine.dll royalty free, but the DDT can't be deployed without a license.

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.

OK. Like I said earlier this week "you cant fight the man".



I will miss is very much though, for making on site adjustments at my clients, now I will have to buy a real laptop I guess that will run VS2005/SF/DDT to accomplish this




Keith Chisarik