Devart Forums

Hi

my dev env is :
- dev/client win7 x86 VS2010 / oracle client 11g x86
- server oracle 9i x86 (physical) and oracle 11g x64 (hyperV virtual machine win2008 x64)

what I am doing is moving
from :
- reverting 9i x86 physical DB to EF4 model to regenerate by code (CreateDatabaseScript() method on the context) & T4 templates new physical DB to 9i x86
to :
- reverting 11g x64 physical DB to EF4 model to regenerate by code (CreateDatabaseScript() method on the context) & T4 templates new physical DB to 11g x64

I am using Direct connection in reverse database wizards.

I am also moving from dotconnect 5.7 to 6 (but I am not sure this is in cause)

I noticed that reverse x64 database in version 6 (can't tell for 5.x version on x64 DB, can't test anylonger) is now converting NUMBER(10) to int (storage) / int32 (conceptual) (either in Entity Developer or VS2010).

I read somewhere here it was supposed to work like that for number(x,y) where x < 10, apparently it is x <= 10 which is for me an error.

I verified that in "my 5.x on x86 system" int64 were generated.
Now that everything in int32, all my code using my models in my solution does not compile at all anymore on my new DB target system.

I tried to use Number mappings to reverse my models but it does not work. (sometimes I noticed it is not even possible to change the field valuetype in the "collection" popup setup for number mappings).

then, don't ask me why, I thought it was may be linked to a new feature of VS2010 SP1 bêta (some new feature of native EF4).
I installed it, it broke my solution explorer view (and also my windows mobile SDK 6 in VS2008, again don't ask me why...) so I had to uninstalled and re-installed VS2010 Premium.
I also uninstalled dotconnect and re-install properly.

then I had to clean my uicache for vs2010 to make new "update" wizards work (thanks to a thread in this forum) so I could do more tests.

Number mappings are not working or I am missing something in their use.
I tried NUMBER(10,0) to Int64, not working.

So I change a field to Number(11,0) in my physical DB, reverse database is now giving Int64 (which is a good news) but I tried a number mapping NUMBER(11,0) to Decimal, not working, still giving Int64. (may be it is not a correct test)

Wizard Model To Database (11g x64) is scripting Number(10,0) from int32/int in the model which is coherent to the reverse database but which is, I think, not correct too.

Then I did another test, revert a x64 DB with number(11,0), got a int64 then change my physical type to Number(10,0) and did a model to db wizard, it script a number(19),
When I was using 5.x version on x86 9i, generating DDL from
CreateDatabaseScript() method on the context produces a number( 18 )

Then I did another test, I got the same physical model on a oracle 9i 32bits (my "old system") and a oracle 11g x64 (my new "system")

So I reverted both models with version 6 :
9i x86 NUMBER(10,0) is OK and gives Int64 in model.
and of course 11g/x64 is giving int32 which is my problem.

in conclusion, use 9i x86 and 11g x64 have different behavior in type mapping (reversing and generating).

so my question is : is this a bug ?

cordialement
Francis

I am sorry, I made new tests.

My conclusions were wrong : this is not a problem between Oracle host OS version x86 x64.

I moved back to dotconnect 5.7 and I got NUMBER(10) reverted to Int64 in my model (on both oracle system x86 or x64)
I checked on another computer with dotconnect 6, NUMBER(10) are reverted to Int32 (on both oracle system x86 or x64)

I think the problem on generating Int64 to NUMBER( 19 ) will also exist.

cdt
FdF

Thank you for your report, we have reproduced the issue. We will consider changing these mappings back (i.e., map Number(10) to Int64 and Number(19) to Decimal), and will inform you about the results here. As a temporary workaround, you can change the types manually.

As for the Number Mappings connection string property, it specifies the type which will be returned by the OracleDataReader.GetValue() method. At the moment, it should not affect the default mappings used for the EF models. We plan to implement this functionality, but cannot provide any timeframe for this.