[mapserver-dev] oid too large (row number uint32)

[Lime, Steve D (MNIT)]

Which version of MapServer? What is the symptom of the error? Is your MapServer install on 32-bit machine? Might just need to fiddle with the definition of resultObj in  mapserver.h. Right now the shapeindex, the structure member that carries a features uid is defined as a long. Could try changing that to unsigned long which would certainly help or use the abstract types (e.g. ms_uint32). Recompile and look for type warnings.

Steve

-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Bart van den Eijnden
Sent: Wednesday, December 11, 2013 3:05 PM
To: Jeff McKenna
Cc: mapserver-dev at lists.osgeo.org List
Subject: Re: [mapserver-dev] oid too large (row number uint32)

Hey Jeff,

I don't think there is an issue number. In the past people have been advised to work around this, but unfortunately in our case this is not an option.

So I am trying to get a feeling for how feasible it is to patch a local version of MapServer for this. If it's feasible (I can't judge), I'm happy to open up an issue for further discussion.

Best regards,
Bart

On 11 Dec 2013, at 22:02, Jeff McKenna <jmckenna at gatewaygeomatics.com> wrote:

> Hi Bart, I am interested in this issue, to follow along...is there a 
> related issue number?
> 
> -jeff
> 
> 
> 
> On 2013-12-11 3:21 PM, Bart van den Eijnden wrote:
>> Hey list,
>> 
>> we are running into the issue where the PostgreSQL oid's are getting too large for MapServer's uint32 row number variable (as described here [1]). It has unfortunately taken down the query function from the GIS portal that we run.
>> 
>> Is it feasible at all to modify the MapServer source to deal with larger numbers (we could modify our local install)? Or would this influence too many things in the code base? Is there a performance / memory penalty to be paid?
>> 
>> A lot of tables / views have no suitable primary keys unfortunately, and doing an initdb on the database is also not feasible in our case.
>> 
>> TIA for any guidance.
>> 
>> [1] 
>> http://lists.refractions.net/pipermail/postgis-users/2004-May/004739.
>> html
>> 
>> Best regards,
>> Bart
> 
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev