Our shop of 6 editors on a versioned SDE instance on a SQL Server 2005 database has been increasingly running into times when reconciling fails and getting a "null Z values/empty geometry" error message (screen shot attached). Up until today, it's happened on small edits so it's been easier to just delete the version and redo the edit than to try and track down the problem. But now I've run a process that took all weekend and come back to find this error when I tried to reconcile the version containing the results.
It occurred to me recently that I believe that this started happening only after we put our parcel fabric into production in this same geodatabase. Since I think the fabric is the only feature class that we have that's Z-aware, this makes some sense. Anyone else have any experience with this? Regardless of the cause, is there a way to fix this?
Thanks Jason. It's still happening, but perhaps with slightly lower frequency. More thorough compresses (but still almost never all the way back to state 0) performed more often have seemed to make things slightly better.
Since my last post, we've discovered that one editor (out of six) has never once encountered the "z value" error while reconciling. The rest of us, though, all seem to encounter it at the same times (very roughly once per week). Interestingly, I wrote some ArcObjects code in '07 or '08 that automated some of the version management for our users, and the one unaffected user has never used these tools while the rest of us have. But if my code is the problem then why only after three problem-free years, and why only sometimes? I'm not afraid to blame my less-than-stellar .NET skills for this, but there's gotta be another contributing factor somewhere . . .
I can ship you whatever you want, so sure you can have some data. But since we're not sure what's causing the problems (at least no one on my end is), would this have to be a copy of our entire SDE database? That won't fit in an email. 🙂
Maybe a backup of the GDB might work. What are you running on? SQL Server?
Here are the instructions to load files on to our FTP site if you want to use that. However, this site isn't secure so if there is anything sensitive I wouldn't recommend loading it:
External users who need to FTP a file to Esri should be instructed to login to ftp://ftp.esri.com/ as " anonymous " using their e-mail address as the password and to navigate to the /pub/incoming directory. They can then put files in that directory.
I am also unable to reconcile and post a total of 8 versions to our 10.0 SP2 GDB. I had not considered null geometries being the culprit. We have a total of 587598 lines with a shape.len value = 0. What was the result from the GDB backup Dan and Jason?
Great question, John. I wish I could answer it. We're in the process right now of testing whether or not the culprit for us is custom .NET ArcObjects code that I've written. That's all been removed from all users' machines and it seems like we're experiencing less problems (not NO problems, but far less). Unfortunately, this test coincides with a decrease in the number of edits being done as we just wrapped up a big project, so the decrease in errors could be explained by the decrease in edits as easily as by my suboptimal (to say the least) ArcObjects code. We never successfully got a backup to Jason, since the ESRI FTP site blows things away two days after they're put there, and it takes a good portion of that time just to upload the whole thing.