500 Internal Server Errors

[Roland Martin]

Hi Luis,

Thanks for your reply. I don't think that's the problem, but here are some
excerpts nonetheless:



  LAYER                     # this one works
    NAME "Contours"
    GROUP "Height"
    STATUS OFF
    CONNECTIONTYPE postgis
    CONNECTION "dbname=lba user=postgres password=postgres"
    DATA "geom from height_data"
    TYPE LINE
    LABELITEM "height"
    CLASS
      EXPRESSION ('[layer_name]' = 'C900LX000')
      COLOR 204 51 0
      LABEL
        FONT sans
        SIZE small
        COLOR 100 100 100
        OUTLINECOLOR 255 255 255
        POSITION auto
        ANTIALIAS false
      END
    END
  END

  LAYER                           # this one doesn't
    NAME "Background Drawing"
    GROUP "CAD Drawings"
    STATUS OFF
    CONNECTIONTYPE postgis
    CONNECTION "dbname=lba user=postgres password=postgres"
    DATA "geometry from background"
    TYPE LINE
    CLASS
      COLOR 51 102 0
    END
  END

The geometry column names are different because I generated the tables from
2 different sources - but that shouldn't make any difference...

Cheers,
Roland.



On 13/07/06, Luis Treviño <ltrevinoh at gmail.com> wrote:
>
> Roland:
>
> Could be the "DATA" sql statement on your map file. It would be easier if
> you can show part of your map file that involves the postgis layer.
>
> Regards,
> Luis
>
>
> 2006/7/12, Roland Martin <roland.w.martin at gmail.com>:
>
> > OK, this is probably yet another stupid query to which I should know the
> > answer... however, I'm on a roll here.
> >
> > I've got an application which is intermittently (i.e. most of the time,
> > but not always) throwing a 500 Internal Server Error. The application is
> > almost a direct clone of another which does not exhibit the same error.
> >
> > I've spent most of the afternoon trying to figure out why this might be,
> > and as far as I can tell, it's something to do with the PostGIS database
> > which holds most of the data. If I remove all the PostGIS layers, it seems
> > to work fine (although interestingly doesn't work if they're all in the map
> > file but turned off - does MapScript try to load the layers regardless?)
> >
> > The database contains converted CAD (DWG) data with typically stupid
> > contents (meaningless fields, escape characters, etc). I wondered if it
> > might be to do with the sizes of the tables (>30 000 records in each), but
> > dissolving them doesn't seem to have made much difference. At the moment I'm
> > leaning towards thinking it may be because of the aforementioned escape
> > characters (looking down the tables, a number just contain the entry " which
> > might upset things; others start with an asterisk). However, some of the
> > tables causing the issue don't contain anything nearly as nasty.
> >
> > The error is being thrown on loading the map; approximately 80-90% of
> > the time.
> >
> > Also of interest may be the following gunk from the error logs:
> > [Wed Jul 12 16:29:11 2006] [error] [client x] Premature end of script
> > headers: php-cgi.exe, referer: http://x/lbia_dev/
> > [Wed Jul 12 16:51:08 2006] [error] [client x] Premature end of script
> > headers: php-cgi.exe, referer: http://x/lbia_dev/
> > (etc)
> >
> > Anyone have any thoughts on this?
> >
> > Ta,
> > Roland.
> >
> >
> > MS4W 2.0
> > MapServer 4.8.3
> > Chameleon for MS4W 2.4
> > PgSQL 8.1
> > etc 1.0
> >
> >
> >
> > --
> > Please note my new email address. Use other addresses at your peril.
> >
>
>


-- 
Please note my new email address. Use other addresses at your peril.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20060713/83fc0d04/attachment.htm>