Haris, et.al. It certainly looks to me that you are on the right track here. It is an established fact that the .NET(managed) connection object in 10.2.0.3 does not behave properly. (See Oracles OTN forum on .NET) The issue in .NET is the connection "Pool". To be brief the issue in .NET: With "Pool" set to false: a) the connection object never times-out, never dies. In addition, and even though a newly created objects "signature" is identical, a new connection gets created. It looks like, in real life, Pool=false means: always create a new connection object and keep it around until the instantiating process dies. The work around here is to keep track of the connection object and just keep using this one. Yes, FDO2FDO “appears” to exhibit this same behavior.
With "Pool" set to true: a)it appears user defined types(UDT's), which sdo_geometry is on the client side, if not resolved with the first invocation of this particular connection object will NOT resolve later on. This appears to be an issue with the connection objects cache storage. The work around here to set “Pool=false”!!! GOTCH’A All of this becomes evident, at least in my case, when working with tables of 100,000+ rows with applications totally unrelated to FDO. All that being said, IMHO the issue is Oracle Clients not behaving as advertised. If there is/are issues with the FDO provider it will be impossible to discover until it is discovered which Oracle client actually works correctly. r, dennis -- View this message in context: http://www.nabble.com/Please-help%21-Has-anybody-used-King.Oracle-in-real-conditions--tp19793029p20065401.html Sent from the MapGuide Users mailing list archive at Nabble.com. _______________________________________________ mapguide-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapguide-users
