Home > GIS > Differences between server & desktop behaviors

Differences between server & desktop behaviors


One of the projects I’ve worked on requires an annual regeneration of the input datasets. In the past, we’ve run the process in multiple small chunks on 2-3 different desktops. Other than the normal shakeout (it is a once a year deal, so people forget some things), we haven’t had a problem. 

This year, we got a shiny new server and thought we’d take advantage of the speed to move things along a little faster. Until it crashed. Repeatedly. We checked the licenses;  we checked the datasets; we checked the permissions; we tried it on the desktop again just to make sure. Nothing.

After a day, we started talking about the time periods of the data. Turns out, we were starting earlier in the year when the greenness layer is mostly no data. The process on the server was failing when it tried to access a zonal statistics table with no records; all of our regions fell in the no data areas. On the desktop, this situation is handled when the cursor returned a null row and skipped to the next step. There are checks in the code for just this situation. But on the server, it crashed on the query to populate the cursor. Why it crashes instead of just returning null, I don’t know. It’s one of those magical ArcObjects moments.

So, to summarize, if you are using a Table.Search call in an ArcObjects that will be utilized in server and desktop environments (and just in a basic ArcGIS desktop application), put in some error handling for the Search call to handle your no data situation. It is a lot easier to do that than it is to troll through 20 years of data.

Categories: GIS
%d bloggers like this: