<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.2900.3157" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Thanks for the quick responses. Since memory usage is the main tradeoff then, for my current project, being able to access the 4000 character columns outweighs the 16x increase in memory use.</DIV>
<DIV> </DIV>
<DIV>I created ticket #2260 as Umberto suggested to further discussion on this item.</DIV>
<DIV> </DIV>
<DIV>This is the first ticket I have created, so let me know if there is something amiss.<BR><BR>>>> On 8/23/2007 at 11:48 AM, Fernando Simon <fsimon@univali.br> wrote:<BR></DIV>
<DIV style="PADDING-LEFT: 7px; MARGIN: 0px 0px 0px 15px; BORDER-LEFT: #050505 1px solid; BACKGROUND-COLOR: #f3f3f3">Hi all,<BR> The way that Jim used is the correct way. The purpose of the <BR>TEXT_SIZE is this, permit to read big strings. If remember, the default <BR>value (256), is because the cell space in DBF, for shapes, can't store <BR>values bigger than 256.<BR> The unique problem is that the usage of memory will increase, the <BR>Oracle driver will always use the 4000 bytes.<BR> We can improve this value (like 1024), but I believe that will cover <BR>just special cases, and the memory will be allocate without use.<BR> Best regards.<BR><BR>Fernando Simon<BR><BR>Umberto Nicoletti wrote:<BR>> Your solution is ok and is the only way to read values longer than 256<BR>> bytes from Oracle. We should definitely consider upping the the length<BR>> of TEXT_SIZE to 4000 once for all. Please file a ticket at<BR>> <A href="http://trac.osgeo.org/mapserver">http://trac.osgeo.org/mapserver</A> so that we can include it in the next<BR>> releases.<BR>><BR>> Regards,<BR>> Umberto<BR>><BR>> On 8/22/07, Jim Klassen <Jim.Klassen@ci.stpaul.mn.us> wrote:<BR>> <BR>>> I am trying to access a spatial table with a VARCHAR2(4000) column from one<BR>>> of our Oracle spatial databases. Things work great for mode=map, but for<BR>>> mode=nquery I am getting an error returned by mapserver in<BR>>> msOracleSpatialLayerGetShape() that Oracle had to truncate one of the<BR>>> fields.<BR>>><BR>>> I noticed that in maporaclespatial.c TEXT_SIZE is defined to be 256 and this<BR>>> seems to be used to determine the size of the pointers and the max allowed<BR>>> column length passed to oracle in OCIDefineByPos(...) on line 2155 in<BR>>> msOracleSpatialLayerGetShape(). So, I changed TEXT_SIZE to 4000, and<BR>>> recompiled Mapserver and now I get the expected result of the entire value<BR>>> of the column being substituted into the nquery template.<BR>>><BR>>> Are there any negative consequences of making this change (except for<BR>>> greater memory usage) that I am not thinking about?<BR>>><BR>>> Is there an easier way to allow columns with values > 256 characters to be<BR>>> displayed in an nquery template that I overlooked?<BR>>><BR>>> I am using Oracle 10gR1 and Mapserver 4.10.2.<BR>>><BR>>><BR>>> <BR>><BR>> <BR></DIV></BODY></HTML>