I'm maintaing an ArcSDE client application which apparently was working with ArcSDE 9.1
Current configuration: ArcSDE 10.1 with Oracle 10.1, Win 7 x32/x64
Symptoms when calling SE_stream_calculate_table_statistics() with SE_DISTINCT_STATS as mask on a STRING property:
1. crashes with SE_NET_FAILURE (-10) 2. memory violation when using direct connect in sdeora11gsrvr101.dll 3. Works fine with numerial properties (integer/double) 4. Works fine with SqlServer with any property type (integer/double/string)
Note: 2) and 3) prove the code is correct.
Any information greatly appreciated. Thanks in advance.
I double checked and the Oracle server is in fact 'Oracle Database 11g Enterprise Edition Release 220.127.116.11.0 - 64bit Production'.
This means there is no compatibility issue. As a matter of fact the application works very well except for this particular function. Is there an known bug? I have been looking around in vain for other users experiencing the same.
Have you applied SP1 to 10.1, and applied the QIP on top of that?
Not many folks use the 'C' API, and with Direct Connect, there is no performance advantage to using SE_stream_calculate_table_statistics() over a local query that does the same (though you'd have to write your own distinct value generator from a stream with order_by set).
There are two ways to compile the 'C' API, one of which redefines all functions which take string parameters to use ACHAR (char) and one which redefines all functions to use SE_WCHAR (unsigned short) parameters. There are different SE_stream_calculate_table_statistics functions based on how you compile, and they return different structures (SE_DISTINCT vs SE_DISTINCTW) with different member types (SE_VALUE vs SE_VALUEW).
Do you compile with SDE_UNICODE enabled (SE_WCHAR parameters) or not?
At least the server code is consistent -- SE_DISTINCT_STATS computation on an SE_NSTRING_TYPE column crashes both SE_stream_calculate_table_statistics and SE_stream_calculate_table_statisticsW with 10.1 SP1 (no QIP).
It doesn't crash on 10.2.0, but it doesn't produce correct output either.
That leaves you with two options -- Using SE_STRING_TYPE columns (with AL32UTF8 character set for international characters) or coding your own distinct function for SE_NSTRING_TYPE cols.
You should certainly contact Tech Support (and have them contact me for sample code to demonstrate the problem).