Problems accessing table with SDO_GEOMETRY type

[eelias]

hi there,

We are using UniDac 6.2.9 for RAD Studio 10 with Oracle 11g

I am trying to open a table (TUniTable) that contains SDO_GEOMETRY field, using direct mode.

After some records loading it raises and exception:

"First chance exception at $767CD8A8. Exception class EOutOfMemory with message 'Out of memory'. "

I see also that SDO_GEOMETRY is expanded to its properties, is there a way to control this behavior? It brings back an array of 99 expanded fields (one field created for each dimension) however I have data up to 155 dimensions.

[AlexP]

Hello,

We have already fixed the problem, this fix will be added to the next ODAC version.

[uffek]

When can we expect next release? It prevents any further development.
Perhaps a hot-fix for a few dcu files on D10 is enough to get us going?

[AlexP]

We plan to release the new ODAC version next week.

[eelias]

I am able to make it work with the current version setting the TUniTable.SmartFetch.Enabled := true;

At least for testing and development purpose it is working.

When I access the Oracle Table using TUniTable it expands the GEOM object from the tablet in a set of properties. That is working fine.

However 2 of these properties are vararrays, one is the SDO_ORDINATES vararray, from where I get the points coordinates.

The problem is that it is returning as a fixed set of 100 SDO_ORDINATES, so I am limited to 50 points (x and y)

I have some geometries with up to 160 or more points, requering that SDO_ORDINATES reaches 320 entries.

How can I control this behavior on UniDac?

I want to be able to get all the dimensions available from the Oracle Table.

[AlexP]

Yes, currently, the number of items is limited by 100. We will change this behavior in the next version. For now, if you have UniDAC with source code, I can send you the needed changes.

[uffek]

We have the version without source code, but since next version should be released this week, we'll wait.

[AlexP]

The new version will be available today already. All the fixes and tests have passed, therefore this behavior change will be included in one of the next versions.

[uffek]

Can you tell us how that change is going to be? There can be 1000's of coordinates.
When reading the same kind of data from MSSQL and PostGIS, it works quite easily with bytearrays and strings. Perhaps you can do it the same way in Oracle? MSSQL being the easist to work with.

[AlexP]

We will change this behavior in the next version. We will add possibility to set these arrays size. Unfortunately, we can't create these arrays with required size, since Oracle doesn't return the actual length, and creation of maximum available arrays will lead to memory loss.

[uffek]

Can you tell us why you don't do it the same way as MSSQL? That is returned as a bytearray. Returning the coordinates as 1000's of floatfields seems like a very strange choice.

[AlexP]

We will also consider the possibility to change these fields type

[uffek]

I have to re-raise this matter:

When will there be a new version where this is fixed?
There is a maximum and fixed number of coordinates being returned, even for bigger objects with >50 nodes (or 100 x/y value).

[AlexP]

No, this behavior is not changed yet. Currently, array max length is 100 elements. We are working at this.

[uffek]

Is there a status on this issue? Something new for next release?