Exception has been thrown by the target of an invocation. A column named 'created_user' already belongs to this DataTable.
I have users attempting to export their identify results as .xlsx or .csv tables, but whenever they do so, they get the error "Exception has been thrown by the target of an invocation. A column named 'created_user' already belongs to this DataTable." We do have editor tracking turned on for the feature class in SDE, and always have. This exact functionality worked as of last week. I followed the recommendations as per a similar post (regarding Print Map and Export), and reran the Post Installation tool, but that did not work. I have also stopped and restarted Core on both our Essentials as well as our Analytics servers. We are on Essentials 4.7.1.42. and HTML5 2.8.2. Any thoughts would be much appreciated. Thanks.
0
-
If this is happening with the builtin tools then it sounds like a bug to me, I'd open a support case. If this is in a workflow, check out where you're building the data table for export because you are aparently trying to give the table to columns with the same name and .net doesn't like it when you do that. I'd also make sure that your service doesn't have any column names or aliases that would look like duplications of 'created_user'. I would also say that there's an outside chance that merely republishing the service will bump the problem away, although if you look at a query against the service and don't receive more than one instance of that field in the json "fields" and "fieldAliases" tags then the chance of a service republish helping move much further outside. 0 -
Thanks for the response Zack. It looks like it has something to do with the Enterprise Geodatabase and/or the service. While the feature class only has a single field called 'created_user', the service contains two. I have republished the service and that does not fix the issue. My gut feeling is that it has something to do with the Enterprise Geodatabase and some changes that happened with the SQL table structures between 10.4 and 10.5. Since upgrading, we have noticed multiple issues with our Enterprise Geodatabase, feature class names, field names, and table structure. I'm afraid it didn't dawn on me until after I posted this question that this might be the issue. My "fix" for the time being is to hide the 'create_user' field. It isn't a critical field at this point, so this will work until we can get the root issue solved. 0 -
Heh good luck with your Arc Enterprise, sounds like you'll need it. 0 -
Thank you! It's been a rough year for our Enterprise system! 0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
4 kommentarer