INFO:

a) I have SQL 2005 and SQLExpress running on the same machine.

b) However, through services, I just stopped SQLExpress running try to isolate the problem.

c) If I go to DDT and look at the local connection, "StrataFrame Data Store" that has connection with StartaFrame database.

d) I can create profile and database and tables with no problems.



However, my problems starts as following:

a) I went to "SQL Management Studio) and created a new database "MyDatabase", since I couldn't create a new database in DDT.

b) In DDT, I create a new connection with different name (than "StrataFrame DataStore") to connect to "MyDatabase". and as soon as I try to create new profile, I get error:





c) If I use "StrataFrame Data Store" connection name with a different database name (MyDatabase), I can open/create a profile and tables. However, If I go to "MyDatabase" with SQL Management Studio, no tables are created. In fact I don't know where the tables are created.



Question:

a) Isn't DDT a replacement for SQL Management Studio to create my tables?

b) What am I doing wrong that I can't freely switch between connections? Like in VS and create tables in "MyDatabase" Database?



Thanks!


..ßen

After using SQL Management Studio and looking into StrataFrame Database, I see tables with names: DBEFields, DBEIndexes, DBETables and etc. that contain all the table's info I had created.



a) Now, Doesn't DDT create these actual tables in my designated database live?

b) Do I have to go through some batch process to create database and tables on my development machine?

c) Do I do this after each table is created or when all the tables have been created?

d) Is this process called "Deployment Package"? If yes, my understanding was that "Deployment" happens when the application is ready to be deployed on user machine and not while development?

e) And what if I make changes on the current tables? Do I need to redeploy it again on my development system to affect the physical tables?



Sorry for all these questions, but it's kind of ambitious!



Thanks!

..ßen

This confused me too. You have to deploy the database to your dev environment. Creating it in the DDT just saves the meta data about the schema. You have to deploy it for that schema to actually exist in a database.



The second button from the left in the toolbar, "Deploy to Server", is what you want. Be sure to create a new package too, to get the latest changes.



I'd deploy as often as needed to program against it. I.e. you might build a table, deploy it, the go into app and build BO against it. Or you could build a bunch of tables, then deploy them all, then build all the BOs. What ever works. But you have to deploy the database before it is actually in SQL server.

Thank you so much Greg;

Ok, it's getting a bit more clear. So, every time any change is made, I need to follow two steps:

a) Create a package to affect the existing database

b) I then need to do partial rebuild of my BO, to affect the properties


..ßen

Very, very close



a) Make changes to SQL Schema in DDT.



b) deploy your changes. This is done via the deploy button. As part of that, create a new package. This creates a new package, then applies the package to the target database. Doesn't matter version target is at (as I understand it), it'll get updated to the schema in the package (which is the latest schema).



c) Then, as you mentioned you would need to do as much a rebuilding on you BOs as needed to get the latest changes. You might also need to build new BOs for new tables/views, etc.



d) Update the code using those properties changed in the BOs. I.e. if you had a field in table MyTable called BaddlyNamedColumn, then changed it to MuchBetterNamedColumn, you could potentially have code referencing BaddlyNamedColumn, which would break after the MyTableBO was rebuilt. This is pretty easy because it will break the compile in most cases. There are a couple of cases where you'll need to do a bit of digging. You might need to search also if you are using code like:







You might also will need to check all the binding field properties that referenced BaddlyNamedColumn for bound controls. I think the property is set via a string in the designer file, so it wouldn't break until you ran it.



I've done steps a-c a bunch. In most cases, all the changes are either found on compile, or related to data binding. I try not to use the Item("") as it is a pain to find

Thanks Greg; I still need to get a grip on the "String Connection", which was the first part of this problem. Hopefully, Trent will go over this stuff in the class to make it clear!

..ßen

Yes, we will definitely be going over setting the connection strings for both your application and the DDT's connection string.  The DDT's connection string always needs to point to the StrataFrame database because that's where it looks for the information for the meta-data.  Then, like Greg said, to get your changes to the server, you need to deploy them using the deploy button on the DDT. 

You can use the DDT like SQL Server Management Studio to maintain your database, but the strength of the DDT lies in it's name... Database DEPLOYMENT Toolkit.  It's meant to be used in conjunction with your product to deploy your needed database schema on a customers site without the use of scripts.  So, you define the the structure in the DDT, package up the meta-data and use the MicroFour StrataFrame DBEngine.dll to deploy the meta-data and create the database on the customer's site.  Without the DDT, you would have to manually maintain a large set of database scripts to create/update the database on the customer's side.

So, the DDT is not a direct replacement for the SSMS, but rather for the scripting necessary to deploy the database with your product.

Hi Ben; Thanks for the reply and also keeping the suggestions into considerations.



That was the point that I couldn't find in help and was driving me crazy. That makes it more clear!





No problem!





That's how I always understood it that is really used to deploy to end user. But, what is not clear in the docs, is that, we also have to do that on our development system every time changes are made.



Is it possible when a table is changed/added in DDT, it automatically reflects the actual tables, to prevent any chance of forgetting to do that manually?




..ßen

This really is not a safe thing to do from our perspective and presents a lot of other questions and issues.  If automated, you would spend a lot of time sitting around waiting since the entire database environment has to be evaluated each time the meta-data is deployed.  Second, it would make it more difficult to use the DDT to create faux environments, something that we will cover in class.  You will actually spend far less time clicking the button to re-deploy than taking the other approach.  The DDT is not designed to replace SQL Server Management Studio but rather provide a facility to create SQL Server meta-data which can then be packaged and deployed over and over again without using scripts and with a level of intellegence that allows the database to be evaluated and updated without having to go through a series of versions and cycles. 

Thanks Trent;



I do have a couple of alternative questions,but I'll just wait to bring it up in the class when the subjects comes up.

..ßen