Hi. I installed the new version dotCoonect for Oracle: dcoracle670pro.exe
I have noticed the diagram generates most of my number columns as long, instead of double like it used to be before.
Does that mean from now on DevArt will stick to long data type rather than double?
The reason I am asking is if I have an old table in my diagram, and add a new one - association gets generated but with RED line. that's because old table has double as PK, and new table has long as FK.
If this is going to be consistent in a future I can convert all my doubles to longs and be done with it. But I don’t want to have to change this in a future again.
So, my question is: Is it safe to assume from now on most numbers columns in ORACLE will be interpreted as long? No More doubles?
thanks
version 670 question
Two ways to resolve the problem with an invalid association:
1. Change long data type back to double for the corresponding property in your model.
2. Navigate to the Tools > Options > Servers' Options > Oracle menu of Entity Developer and customize mapping which will be used in the Database First approach on your workstation. Be aware that these settings are global (for all newly created models), they do not affect the current model, reinstall doesn't change mapping rules (use the Reset button to restore all the options to those predefined by Devart).
We have changed a bit mapping (fixes of bugs) when the "Capability for customizing the default Type Mapping Rules is implemented" feature was introduced. If you consider the new mapping as incorrect, please tell the data type (NUMBER(x,y)) of your column which is mapped in a wrong way now.
1. Change long data type back to double for the corresponding property in your model.
2. Navigate to the Tools > Options > Servers' Options > Oracle menu of Entity Developer and customize mapping which will be used in the Database First approach on your workstation. Be aware that these settings are global (for all newly created models), they do not affect the current model, reinstall doesn't change mapping rules (use the Reset button to restore all the options to those predefined by Devart).
We have changed a bit mapping (fixes of bugs) when the "Capability for customizing the default Type Mapping Rules is implemented" feature was introduced. If you consider the new mapping as incorrect, please tell the data type (NUMBER(x,y)) of your column which is mapped in a wrong way now.
I don't think the new mapping is incorrect.
for Example NUMBER(10) used to be mapped as double,
and now it is mapped as long.
I have old entity "Job" with "JobID" column mapped to double.
When I add a new entity that has relations with Job, the same column "JobID" is mapped as long. I am aware I can change the data type to double in new entity in order to resolve the associations problem.
But I am trying to avoid this manual fix, so my question is:
Is it safe to do a global replace and switch all my doubles (for Number 10) in entities to long? If I do that the data type will match when I drop the new table.
thanks
for Example NUMBER(10) used to be mapped as double,
and now it is mapped as long.
I have old entity "Job" with "JobID" column mapped to double.
When I add a new entity that has relations with Job, the same column "JobID" is mapped as long. I am aware I can change the data type to double in new entity in order to resolve the associations problem.
But I am trying to avoid this manual fix, so my question is:
Is it safe to do a global replace and switch all my doubles (for Number 10) in entities to long? If I do that the data type will match when I drop the new table.
thanks