Antwort: Re: [UMN_MAPSERVER-USERS] Problem with long DATA object in an Oracle LAYER

[Damien Corpataux]

Hi Benedikt,

Thanks for the tip. My problem is that the queries are highly dynamic.
Using views would imply view managment (creation, cleanup). I'll keep
that idea if I run into problem with Andreas' solution.

Thanks, and regards,
Damien Corpataux

Benedikt Rothe wrote:
>
> Hi Emmanuell
>
> If your project is stuck with this problem: In cases like this, I
> always try to avoid long SQL-statements in mapfiles
> anyway. Instead I put the complexity in a  view and use in the mapfile
> just this view.
>
> Benedikt Rothe
>
> UMN MapServer Users List <MAPSERVER-USERS at LISTS.UMN.EDU> schrieb am
> 10.09.2007 18:28:00:
>
> > 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)


-- 
Camptocamp SA
Damien Corpataux
PSE A
CH-1015 Lausanne
+41 21 619 10 22 (Direct)
+41 21 619 10 10 (Centrale)
+41 21 619 10 00 (Fax)
P Please consider the environment
Do you really need to print this email?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20070911/072b6d3d/attachment.htm>