Python tool output not writing to correct location

[AnthonyCheesman1]

Good afternoon everyone

I'm sure there is a very easy answer to this question, but I am banging my head against a wall, and I need outside assistance.

I have written a script that iterates through some tiled data, manipulates it and writes the output (which should be a polygon) to a feature dataset within an fgdb.

For some stupid reason, the output is not writing to the correct f/dataset but rather is writing it as a table to the fgdb. Confusingly, the table contains a 'shape' field.

What is more frustrating is that this script has run perfectly on a number of occasions, and I have made no structural changes to it other than changing some workspace paths.

What is even more frustrating is that it has run perfectly since the workspace paths have been changed, but is now falling over for no reason that I can see.

The only possible cause I can think of is that the fgdb structure has become corrupted, as there is quite a bit of data written in and out as part of this process. The tool does compact the fgdb on every 5th iteration, which is nominally when about 750 meg of data has passed through, which seems to be the magic number for improving fgdb performance by compacting.

Is there anything stupid that I have missed? Why would this be misbehaving so badly? It all seems quite arbitrary and I don't quite know why.

[RhettZufelt]

So, what happens if you make a new FGCB and FD and have it write to there?

This will rule out the FGDB being corrupt if it still doesn't work.

I assume you are not trying to start the FC name with a number, and the same name isn't used anywhere else in the FGDB (either inside the FD or at the root level)?

R_

[AnthonyCheesman1]

Have done just exactly that Rhett - created a new fgdb, moved the relevant data across and remapped the path names in the script.

It *appears* to be running ok now, tested successfully on one tile, now attempting to run on the full set (want to make sure that it is iterating correctly between tiles).

I've also added an additional step, as the process creates some fairly complex polygons - so I am repairing geometry on the source polygons before this process starts.

What is most frustrating is that this is a big batch job and ideally needs to run overnight to complete. I especially came back into work last night to get it running and came back in this morning (on a Saturday, on a long weekend) to see that it had fallen over.

Fingers and toes crossed...

[Leandro-Zamudio]

Hi Anthony.

Is there a way i can check your code (via GIST or attachment) to see if there's a problem?

Greetings

[AnthonyCheesman1]

Hello Leandro, thank you for your offer.

I seem to have resolved the issue; I suspect there was a corruption in the original fgdb structure which was causing the error. I migrated my data to a new fgdb and redirected the script, and it completed as expected.

The output was not what I was hoping for, but that is more to do with my script logic than anything else.

I'll need to spend a few hours this weekend working on it.

Thanks

Anthony