Timeline for Using CopyFeatures_management without copying source GDB domains to 'in_memory' workspace?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 7, 2016 at 23:19 | history | edited | PolyGeo♦ | CC BY-SA 3.0 |
added 1922 characters in body
|
| Oct 7, 2016 at 21:58 | comment | added | umbe1987 | I think it does create domains, and I am asking how to avoid this (if possible). I will come back to my script and update my question with the tool I am using to push the 'in_memory' temporary FC to the final GDB to let others replicate this behaviour. Meanwhile thanks for the replies. | |
| Oct 7, 2016 at 21:49 | comment | added | PolyGeo♦ | It should be easy to test whether a feature class copied into an in_memory workspace and out again to a new file geodatabase creates domains there. | |
| Oct 7, 2016 at 20:44 | comment | added | umbe1987 | I know this. I also know that the 'in_memory' workspace is a FileGDB itself, and I am wondering if when I do "CopyFeatures", the 'in_memory''s GDB itself changes its properties, inheriting the Domains from the source GDB from where the FC is copied from. Is that possible? | |
| Oct 7, 2016 at 20:44 | comment | added | Midavalo♦ | It appears (from OP's comment) that the domains are being copied through the in_memory into an output geodatabase. There may be a bit more to it. | |
| Oct 7, 2016 at 16:21 | history | answered | PolyGeo♦ | CC BY-SA 3.0 |