Bug in Sync field changed into to decimal

Posts   
 
    
Rosacek
User
Posts: 157
Joined: 18-Mar-2012
# Posted on: 30-Jan-2023 11:10:43   

Hi, I changed field datatype from int to decimal(4,1) and run sync from MSSQL to model.

Designer changed field definition from: <Field Name="Qty" Type="int" Precision="10" FieldIndex="12" />

to: <Field Name="Qty" Type="int" Precision="4" Scale="1" FieldIndex="12" />

Means did not change datatype to decimal.

Steps to reproduce: Add new field to table, set datatype to INT. Sync designer. Change datatype of that field in SSMS to decimal(4,1). Sync designer. And check type in LLBLGen designer.

LLBLGen version: 5.9 (5.9.3) RTM build 29-Nov-2022

MSSQL 2019

Walaa avatar
Walaa
Support Team
Posts: 14983
Joined: 21-Aug-2005
# Posted on: 31-Jan-2023 06:21:22   

Reproduced.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39752
Joined: 17-Aug-2003
# Posted on: 31-Jan-2023 08:15:38   

We'll look into it!

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39752
Joined: 17-Aug-2003
# Posted on: 31-Jan-2023 10:04:36   

The reason this happens is that the target framework you're using (e.g. our runtime framework) supports implicit conversions for certain types, like short to int etc. (in general: numeric types) When this is the case, we don't change the type but keep the entity field type the same. This has been the choice since it was introduced in an earlier version. We mainly picked this as there's another option we had to prefer above changing the type: applying a type converter automatically. This is a setting which is enabled by default as adding a type converter is otherwise time consuming. Additionally, perhaps you'd want for this situation to use the implicit conversion (although decimal -> int might be a bit extreme, but e.g. going from short in the db to int is perfectly doable).

The downside of this choice of course is that when you do want to change the field type, it's up to you to do so. Adding a setting for this would conflict with the type converter assignment setting and as that's a setting that would take preference anyway, we didn't add a setting for this, and picked a side: when implicit numeric conversions are supported by the target framework (EF, ours) then it's left to the framework at runtime.

Example: if you change the int db field to a varchar(50), it'll change the field type as there's no implicit conversion possible. If you have a type conversion set with a type converter that can convert varchar values to int however, it'll not change the type to string but will assign the type converter.

I do admit though that this is kind of rigid and more flexibility might be needed, but introducing that has conflicts with other features and to me there's not a way to introduce a setting that's not conflicting with another setting (which then causes friction in that area disappointed ). Additionally, the current implementation works fine for the most part but if you move from an int to a decimal, it will change precision/scale of the field but not the type (precision/scale are ignored on int types anyway). I guess this is because going from an int like type to a decimal or other numeric type with a fraction/scale is the only situation this will occur and we missed that particular situation.

To correct the field, please change the field type in the entity editor to decimal.

What we can do to help in this situation is to add a warning in the sync log perhaps for this? Would that help you notice these changes better so you can manually correct them? A setting won't be added, but perhaps a warning in the sync log might help notify you that an implicit conversion is utilized so the type is kept the same but perhaps you don't want that and you have to manually correct it?

Frans Bouma | Lead developer LLBLGen Pro
Rosacek
User
Posts: 157
Joined: 18-Mar-2012
# Posted on: 31-Jan-2023 10:43:21   

Yes, I use your Runtime Framework for several years. I never noticed this issue before.

For the new project customer changed mind, that quantity could be also decimal. Well that si quick change, isn't it? So I changed field in SQL resync, noticed it in your designer after sync log green bold text info that field definition was changed, so far so good as many times before.

Then in VS I changed Devex grid column format, and... I could not input decimal number, red cross in grid and exception in generated LLBL code, that value cannot be stored into object. I was suprised what the hell it is. After some investigation I found what is reported here.

I am sure you will find the best way how to handle this issue as you always do simple_smile I can also live without any fix or workaround.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39752
Joined: 17-Aug-2003
# Posted on: 31-Jan-2023 17:41:30   

Thanks simple_smile I think we'll go for the warning in the sync log, as that's the spot where we can attend a user on this. We'll also think about adding a warning to the designer validator itself, however users sometimes get a bit anxious when a warning pops up in the designer even though it can be harmless.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39752
Joined: 17-Aug-2003
# Posted on: 01-Feb-2023 10:47:43   

We've released a hotfix build (5.9.4) which will now report a warning in the log shown after a refresh.

Frans Bouma | Lead developer LLBLGen Pro