There are many use cases where we need to change the data type of a column. We have observed the following behavior wrt data type changes and want to understand why this happens.
DB - MS SQL
Behavior #1
Say a column has been created as String(250) and published. Changing it to String(50) via the Object designer and re-publishing it does not change the data type at the data base level - even though it reflects correctly in the Package (We also verified that there is no data in the DB which exceeds 50 characters. So technically, it can be downgraded to 50 characters without loss of data). We are forced to alter the column at the database level to actually downgrade it to String(50).
Behavior #2
On the flipside, a data type change from String to Int does work. Additionally, it downgrades the column from NOT NULL to NULLable type in the Database when the String to Int conversion happens.
Can someone string together the above 2 behaviors and why one happens and the other doesn't?
Is there knowledge within the community as to what data type changes work and what do not? If yes, Pls share your experiences.
Note - I am aware that the earlier column can be dropped and a new column with the new data type be created. But this is not practical, if we want to retain the same name.
We tried to reproduce the behavior you have described for different types of DB (PostgreSQL and MSSQL) in two ways:
1. Create a column via Page Designer.
2. Create the column in Object Designer.
At first, we have set the string length 250 for the 1st column, then changed it to 50 in the Object Designer and published the object:
As a result we could see that the data type has been changed from varchar(250) to varchar(50):
Then we have repeated the same actions for another test column (added via Object designer) and result was the same:
That's why it would be really helpful if you could confirm if we were doing the reproducing correctly (maybe we should use another version or another product). Also, we can provide you with a fresh installation files so you can try to re-check it from your side once again (for that just contact our support team via this email: support@creatio.com).
About the second question: in general, we do not recommend to change field types. The system can transfer data type from one char to another when you need to change the length of the field. But it may behave unpredictably when the type is changed from one object to another.
Alos you can find some addtional information about data types in the links below:
Hi Roman, Appreciate your effort in trying to reproduce this.
Your steps does look right -
1. Create as 250 in Object designer. Publish and check if the DB shows nvarchar(250).
2. Change to 50 in Object designer. Publish and check if the DB has changed to nvarchar(50).
I have verified this on 2 Creatio versions - 7.15.2 Studio and 7.16.3 CustomerCenter (Both MS SQL). Is is possible that this got fixed/changed in the latest 7.17 release?? Il also reach out to Creatio support ato replicate this in the latest release.
Hi Roman. Checked this use case once again. The behavior I have stated in my question is correct. I have used a on-premises Creatio sales v7.17 on MSSQL. The datatype does change if you increase the length (Eg 50 to 250) but not from 250 to 50.
Have you checked this on an on-premises or trial instance??
Maximum value integer field can hold is 2147483647 and you can test in on your side as well - the system won't allow you saving numbers greater than 2147483647.
is there any way to accept bigger values? in my case I'm working a project to manage public works, such as roads, dams, stadiums, etc., and the amounts are very large.
Also I saw I can introduce larger decimal values, this have no logic why I can introduce 52.437.560.581,00 and not 52.437.560.581? In the case of customer they didn't use decimals, price of the public works are Integer
