I've downloaded beta of Devart dotConnect (6.30) and tried to create a new model to generate a database from it. I created a class with several String fields and then edited it's storage model changing field types from CLOB to NCHAR or NVARCHAR2 and setting MaxLength to some positive integer value.
When I tried to generate a database from the model, I received an error saying that the unique or key column can't be CLOB. Most of String columns were reset back to CLOB. I assigned them to NCHAR/NVARCHAR2 again, but they were reset. It worked after some attempts, so it looks that the error is not 100% reproducible.
Eventually I gave up and edited EDML file manually. Still when I loaded it into a Model designer, it reset string types back to CLOB and failed to generate the database.
Oracle: model designer resets NCHAR to CLOB
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
Please specify if you are using the 'Update database from model' or 'Generate database script' wizard, and whether you enable the 'Regenerate Storage' check box when running these wizards. When this check box is enabled, the default server data types are used in the script (the default Oracle type for System.String is CLOB, as string may have more than 4000 symbols). If the check box is disabled, the data types specified in the storage will be used (e.g., NCHAR's and NVARCHAR2's you've set).
Hi Stanislav,
I was updating the database from model and most likely using 'Regenerate Storage' flag, so it may explain the behavior. However I'd say the behavior is erroneos for the following reasons:
1. The CLOB type was selected even for a key column causing an error when generating the storage: CLOB can't be used as a key.
2. The data types are changed without giving any notice. If it's impossible to use any other type, there should not be possible to select it in the first place. I was completely unaware of the fact that types have been changed. I saw it when I expected the model afterwards.
3. Even if there are good reasons for choosing CLOB as a first choice, developer may may have his own good reasons for changing it. I don't think the EF designer should overwrite his choices.
I was updating the database from model and most likely using 'Regenerate Storage' flag, so it may explain the behavior. However I'd say the behavior is erroneos for the following reasons:
1. The CLOB type was selected even for a key column causing an error when generating the storage: CLOB can't be used as a key.
2. The data types are changed without giving any notice. If it's impossible to use any other type, there should not be possible to select it in the first place. I was completely unaware of the fact that types have been changed. I saw it when I expected the model afterwards.
3. Even if there are good reasons for choosing CLOB as a first choice, developer may may have his own good reasons for changing it. I don't think the EF designer should overwrite his choices.
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
Thank you for your suggestion, we will consider mapping string primary keys to some data type other than CLOB by default.
As for the changes being overwritten, this only happens if the 'Regenerate Storage' check box is enabled. This check box should be used to automatically set mappings to all fields (e.g., if the model was created without the synchronization enabled, and the server data types were not set before). It is natural that this option uses the defaults and overwrites the mappings set manually.
As for the changes being overwritten, this only happens if the 'Regenerate Storage' check box is enabled. This check box should be used to automatically set mappings to all fields (e.g., if the model was created without the synchronization enabled, and the server data types were not set before). It is natural that this option uses the defaults and overwrites the mappings set manually.
-
- Devart Team
- Posts: 1710
- Joined: Thu 03 Dec 2009 10:48
We have changed this behaviour: string entity members are now mapped to varchar2(4000). This change is available in the new 6.30.160 build of dotConnect for Oracle. The new build can be dowloaded from
http://www.devart.com/dotconnect/oracle/download.html
(the trial version) or from Registered Users' Area (for users with active subscription only):
http://secure.devart.com/
For the detailed information about the improvements and fixes available in dotConnect for Oracle 6.30.160, please refer to
http://www.devart.com/forums/viewtopic.php?t=21027
http://www.devart.com/dotconnect/oracle/download.html
(the trial version) or from Registered Users' Area (for users with active subscription only):
http://secure.devart.com/
For the detailed information about the improvements and fixes available in dotConnect for Oracle 6.30.160, please refer to
http://www.devart.com/forums/viewtopic.php?t=21027