Roberto, Jeremy Thank's for your remarks.
I decide to use the 'oracleClient1.0' ( System.Data.OracleClient ) so i have no problems with numbers and my query's work fine after i wrote a custom TypeHandler for my varchar columns with null values to hanle empty strings. ( working on oracle 10g ) I am a little bit sad about Jeremy's statement 'the Oracle 9i client performed markedly better' and hope that my application don't need this. On the other hand my DAL seems to work well and i can go further coding my business logic. Just testing transaction bracketeds. Thank you verry much for your work on Ibatis. A useful and well documented project. Roberto R wrote:
Tests were run for System.Data.OracleClient, ODP.NET 9i, and ODP.NET 10g. (I would not recommend using ODP.NET 9i with the DataMapper.) From my experience, System.Data.OracleClient was the "easiest" to use right away, but ODP.NET 10g offers some advanced features that could be used outside of the DataMapper.
Jeremy Gray wrote:
Based on a quick look at the exception, it looks like you've run into the same issue we did, which is that the
provider you are using has difficulties mapping the larger Oracle number types into the .net types.
At the time that we encountered this issue we were only in a position to evaluate the Oracle 9i client and the
Microsoft client. Since the Oracle 9i client performed markedly better, we worked around the problem by modifying our query statements to cast such problematic number fields to varchar and allow ibatis.net to map those back into the desired .net numeric types.
We still have yet to evaluate the 10g client, but I'd like to get to it sometime soon. In the meantime, these
workarounds have been rare, so there's not been much need to push towards the 10g client, as much as I might like to dig into it. -- Kind regards Uwe Lesta at SBS-Softwaresysteme.de
