Question
Set SDE Data type for strings to SE_String not SE_NSTRING
+6- Contributor
It seems that the fme char type for the sde geodatabase writer maps to SE_NSTRING, we have some old ESRI JAVA_API's that don't like this format and are expecting SE_STRING, does anyone know of a way to change the default mapping for the esri geodbwriter in workbench (until we update the java API's)?
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
Hi,
I think you should address your question to Safe support (https://safecommunity.force.com/knowledgeSubmitCase) for the definitive answer on this. I might be wrong, but I suspect FME might not be using those dataypes directly, but rather referencing the more generic "char(width)" in the API.
But could it be that you need to modify the DBTUNE table in your SDE database to prevent the default creation of unicode text fields in your database?
Look for the UNICODE_STRING setting here (http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=DBTUNE_configuration_parameter_name-configuration_string_pairs).
David
+6- Contributor
Thanks for the quick reply David. Our preferred option is to upgarde the API rather than reconfiguring the sde database dbtune keyword.
I've submitted the question to the support desk, to see if there is a hidden quick win in configuring the writer. but is supect you are right.
I'll post a follow up here in case anyone is interested.
Hi,
for what it's worth, I agree that upgrading the API is probably the best solution. Particularly for the long term.
David