Recommended approach after changing attributes of existing entities?

Recommended approach after changing attributes of existing entities?

  
Yesterday, after establishing a relationship between two tables and changing an attribute data type, I could no longer build my app.
After doing some reading, I wound up deleting my screens, deleting my eSpace, rebuilding, and then regenerating my screens.

Obviously, that's not what you intend.  What's the approach/sequence I should take in the future?   Is there an article on this anywhere?      Thank you.

That's a little bit odd, where do you changed that attribute, on service studio or directly on sql?

It looks like you've changed directly on sql....

Best Regards.
No no.   I made the changes inside  Service Studio.   I wouldn't dream of touching the DB directly - not at this point.   Hopefully, not ever.
And you clean up the data from database before submit that change ?

You should clean up the data from the database and refresh or restart the database.

Best regards
Well, I brute forced it by deleting the eSpace, which forced a recreate of the database on the publish.  But I shouldn't have to do that.
And - I shouldn't have to clean the database by hand.

This is the Agile world.  Today, working directly with Sql Server, I can change an attribute of a column - without losing the table and without
losing the contents of the table.  We have to, at a minimum, have that here.   I expect there to already be a way - I'm just hoping for someone
to cite it.

I'm hoping to hear that AP allows for easy ways to change attributes and yet preserve existing data and screen layouts - for most cases, anyway.
That's  Agile,   right?

Things change.
Frank -

There are a handful of scenarios where a Service Studio "publish" can't make a change to an existing DB structure on its own, because it would violate data or referential integrity. The error message on publish will usually make it clear. For example, I had an attribute as Text(5000), and changed it to Text(2000), but Service Studio couldn't change the DB field type from ntext(5000) to nvarchar(2000), because SQL Server doesn't let that happen. I had to make a dummy column, copy the data, drop the original column, copy the data back, drop the dummy column.

Most of the time when this happens, it isn't the Agile Platform having the issue, it's the DB enforcing a rule that exists for a reason (often, one you put in place originally, like a constraint).

Instead of wiping out the eSpace (which is unacceptable in a production environment!), I've found it best to look at the error message and resolve it manually.

J.Ja
When you have one of these sql column upgrade problems, and you don't have any data yet, it's probably easier to just delete instead of doing the manual upgrade described by Justin, but in that case, it's better to delete only the entity instead of the whole eSpace. Just cut the entity and then paste it right back, and the platform will be consider it to be a different entity, so a new database table will be created.

Best Regards,
Gustavo Guerra
Very interesting.

And what about the cases where there Is data.   

Sql Server Management Studio lets me change column attributes without losing data or having to drop the table - as long as
data won't be truncated.   Will AP take away any of these scenarios, or will all scenarios supported by Sql Server automatically
happen inside AP?     Thanks.
Service Studio usually lets you make the changes. In a nutshell, Service Studio lets you make any sensible change, but any issues are found on publish when the DB server balks. The reason is that Service Studio doesn't assume that it's been published or that there is any existing data, which makes sense if you haven't gone to Production yet.

J.Ja
Today, working directly with Sql Server, I can change an attribute of a column - without losing the table and without
losing the contents of the table.  We have to, at a minimum, have that here.   I expect there to already be a way - I'm just hoping for someone
to cite it.

Are you sure about that?
Ofcourse increasing the length of a char-column would be easy.
But changing a column from varchar to integer would cause some interesting issues...


Yup - I'm sure.   I Live inside Sql Server Management Studio, and many types of datatype changes are do-able - without any loss of data or drops of tables.
Hi Frank,

As Justin pointed out, I would expect that changing entity attribute data types would work in Service Studio the same way they work in SQL Server - at least that's the way it is designed to be. Quoting yourself: "Will AP take away any of these scenarios, or will all scenarios supported by Sql Server automatically happen inside AP?" - I'm expecting all scenarios supported by SQL Server to automatically be supported by the Agile Platform.

If you can replicate the problem you had - i.e. which data types you had originally, and what data types did you change it to - I would recommend letting us know more about it, since it might be a bug, and we would want to fix it. Asides from that, I have never had such a problem using the Agile Platform, and I've been developing in it for 6 years or so.

Regards,

Paulo Tavares