"Null z value/empty geometry" error when reconciling

2212
14
03-15-2011 07:13 AM
DanNarsavage
Occasional Contributor
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,
Dan
0 Kudos
14 Replies
JasonCamerano
Esri Contributor
We are looking into this issue.
0 Kudos
DanNarsavage
Occasional Contributor
Any resolution yet, Jason?  Is there a bug tracking number or something that I can follow?  Thanks.
0 Kudos
JasonCamerano
Esri Contributor
Sorry for the delayed response. 
Would you happen to have any data that we can use to reproduce this? 
We have not been able to reproduce this in house.  Is this still happening frequently?
0 Kudos
DanNarsavage
Occasional Contributor
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. 🙂

Thanks,
Dan
0 Kudos
JasonCamerano
Esri Contributor
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.

The file will be deleted in 2 business days.
0 Kudos
DanNarsavage
Occasional Contributor
Okay, we put a SQL backup of our production SDE instance out on your FTP server as you suggested. Thanks Jason!
0 Kudos
JasonCamerano
Esri Contributor
Hey Dan,

What directory is the Backup in.  It might have been removed already...
If you re-upload it send me an email: jcamerano@esri.com and I will pull it immediately.
0 Kudos
JohnFell
Occasional Contributor III
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?
0 Kudos
DanNarsavage
Occasional Contributor
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.
0 Kudos