[mapguide-users] ODBC Points Performance

[Jon Rizzo]

Thanks for the suggestion(s).  That is currently how we are serving up
polygons - they are drawn in an SDF file but joined with data on a SQL
Server so they can be labeled/themed.  The selection of the polygons suffers
from the same problem as our point selection, so it stands to reason that
your suggestion probably will not help.  Our data is updated frequently, so
it's not realistic to copy all of the the data over to SDF files.  Again,
that's really the whole point of having an enterprise database to begin
with.  I think we may have to (*sigh*) continue using ArcIMS.  This is very
disappointing to me, but it just appears to be better at what I'm trying to
do.

Also, I'm not even talking about 5,000 features here.  A typical map for us
has 100 or so polygons and 10-20 points.  Our lag is more like 4 seconds
instead of 10, but that's still enough to make our users crazy.



Ismael Cams wrote:
> 
> I don't know if it is an option for you but it might be sufficient to put
> only the x-y coordinates in an SDF together with a key that can be used to
> do further database queries. These SDF's can be generated out of the SQL
> server database you are using with some code.
> To get properties and other information out of the database you could go
> with an own faster database connection. 
> For the synchronization you could run the job for exporting the geometry
> to SDF every day or so.
> It needs some work, but for a layer with ~ 5000 points I had sometimes to
> wait up to 10s before something got selected ... 
> 

-- 
View this message in context: http://www.nabble.com/ODBC-Points-Performance-tf4201424s16610.html#a12017332
Sent from the MapGuide Users mailing list archive at Nabble.com.