I am having an issue updating table/field structures in the DDT.

I know Trent you saw one instance where I was going from INT to BIGINT on a PK field and said you would look into it.

I have had a few more instances where changes would not take correctly.

On two occassions I was able to get the changes to publish by saving the package as a seperate step, closing and reopening DDT, then publishing.

On a few other occasions I had to undo my changes, or in one instance when I tried to remove the PK field (experiment) without first deleting the index referencing it I had to pretty much rebuilt the table.

Once you got me going with the framework, I sailed through all the tutorials and an sold on the value of the framework. The reliability of the DDT concerns me, please let me know if i am doing somthing procedurally wrong to cause these update issues.

Keith Chisarik

I did confirm that there was an issue with the PK not being dropped if you change the type from one to another.  This has already been add to the "ToDo" list.  As for some of your other problems, I think that you are probably just not doing something quite right.  Just FYI, we use this on a daily basis and there are a few things that you have to know about, such as adding new fields to a table that already has existing data.  You will need to either allow NULL or provide a default value, such as (0) or an integer field or ("") for a character field.  In a normal day, I change and post anywhere from 5 to 20 changes to a server using the DDT.  So it is well broken in.  One other thing, when you installed StrataFrame, all of our structures, and sample data, are deployed using the DDT as well. 

So as for the reliability, I promise you it is there just like the framework. 

To remove a field as a PK within the editor, simply uncheck the "Primary Key" check box, click Save and the index will be automatically removed.

I knew this one would be simple, thanks!

Keith Chisarik

Hmm it seems I still need some help modifying the structure of an existing table that contains data.

I had a table of structure primekey int (4), lastname varchar(20), firstname varchar(20)

I tried to add field email varchar (30).

When I selected "Allow NULLS" as suggested above the packaging and deplyment processes worked. I then remapped my BO, rebuilt my partial, and bound a textbox to my new field. Upon running I get this:

So I tried suggestion #2 above (set a default of ('') for the character field - using the ... provided) and get this when trying to deploy. Help please. It looks like it is trying to insert NULLS even though I have defined a default value?

Keith Chisarik

Ok so I decided to just remove my new field "email". I did that in DDT, repackaged and deployed. All went well.

I remapped using the "Business Object Mapper" , rebuilt partial, rebuilt project.

Well it renamed my BO from CustomerBO to Customer BO1 and that screwed up my code so now things dont work.. I am throughly frustrated. Please help me.

Keith Chisarik

Alright the problem was i think that the remapping using the Business Object Mapper removed my overrride for GetCustomBindablePropertyDescriptors() in my BO.

So..... what is the procedure to update table structures, deploy them to the databsse with existing data, and merge those changes into existing BO's without losing anything (custom properties, etc)?

Thanks.

Keith Chisarik

Well, the problem you ran into has is because the data within the field is NULL and you have not implemented any NULL functionality within your BO.  If you do not plan to support NULL data, which really is the best way, set the default value for a new field to ('')  those are single quotes and SQL Server requires the parens.  This will set the new field data to an empty string.  Likewise, for an integer field you would set the default value to (0).  If you plan to support NULL data, then you will need to go into the BO Mapper and for that particular field *** NULL support.

In our applications we generally never support any NULL data because it causes more problems than it resolves.  So when we add a new field we just set the default value to initialize the data for us like I mentioned above.

It depends on where you placed your code.  Also as for it "renaming" your business object, it doesn't have this ability.  It has to use the existing BO name.  The only way I could this something like this could have happened is if you attempted to assign a pre-existing project with a BO of that name to your current project.

If you place all of your code in the CustomersBO.vb file no code will be overwritten.  If you place code in the Customers.Designer.vb file, well...you will have a bery frustrating time because this code gets overwritten each time the partial is built.