Problem with long DATA object in an Oracle LAYER

[Emmanuel BELO]

Hi Fernando,

thank you for investigating. We need this for a project, where it is not
possible to use PostGIS.

Do you have an idea how long it would take to fix the problem? Can we
help you in some manner?

Best regards,

Emmanuel





Fernando Simon wrote:
> Hi all,
>    I will investigate the problem. I believe that it's relate with the
> msSplitData function in the driver source code.
>    Thanks for the reply about the error.
>    Best regards.
> 
> ---------------------------------------------------------
> Fernando Simon
> UMN Mapserver and Oracle Spatial developer
> 
> Emmanuel BELO wrote:
>> After some investigation, we could identify that this occurs only with
>> an Oracle connector. It's not reproducible with a PostGIS connection.
>>
>> Here our testcase outline:
>>
>>
>>   LAYER
>>     CONNECTION "user/password at myoracleoracle9instance"
>>     CONNECTIONTYPE ORACLESPATIAL
>>     DATA "[Put a query larger than 2037 characters here]"
>>       METADATA
>>       END
>>     NAME "oracle_test_layer"
>>     PROJECTION
>>       "init=epsg:4326"
>>     END
>>     SIZEUNITS PIXELS
>>     STATUS ON
>>     TOLERANCEUNITS PIXELS
>>     TYPE POLYGON
>>     UNITS METERS
>>     CLASS
>>       METADATA
>>       END
>>       STYLE
>>         ANGLE 360
>>         OUTLINECOLOR 255 0 0
>>       END
>>     END
>>   END
>>
>> You can build a large sql query by adding a lot of "always true"
>> clauses, or by padding it with a lot of spaces
>> eg. shape from (select shape from my_table where 'djfksdhfjkdsf' =
>> 'djfksdhfjkdsf' and 'djfksdhfjkdsf' = 'djfksdhfjkdsf' [...])
>>
>>
>> Best regards,
>>
>> Emmanuel BELO
>>
>>
>>
>> Damien Corpataux wrote:
>>  
>>> Hello List,
>>>
>>> I ran into memory corrption with a long sql query in the DATA object,
>>> for an Oracle LAYER. It is obviously due to Mapserver memory allocation
>>> mechanism. The corruption occurs when the DATA is longer than ca. 2037
>>> characters.
>>>
>>> Do you know if Mapserver has a way of modifying the possible allocated
>>> memory limit? In header files? By applying a patch?
>>>
>>> Any idea is welcome!
>>>
>>>
>>> Thanks in advance, regards,
>>> Damien Corpataux
>>>     
>>
>>   
> 

-- 
Camptocamp SA
Emmanuel BELO
PSE A
CH-1015 Lausanne

+41 21 619 10 25 (direct)
+41 21 619 10 10 (centrale)
+41 21 619 10 00 (fax)