Writing to SQL Server can be frustrating if you don't pay attention to the attribute types. Generally Varchar is needed as any whitespace may cause issues with styling data in Arcmap or other GIS programs. The default character type should change to reflect the best types for any given writer.
Released
SQL Server writer Varchar as default
+5This 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.
+26- Contributor
I second this.
For Oracle too the Varchar2 type is highly recommended over the default Char type as the Char type appends spaces to the actual value.
+26- Contributor
The nicest way to do this is using the FME options and being able to set up the default datatype per Writer for character and numeric attributes. You could even add a default precision per datatype (e.g Oracle character: Varchar2(20), numeric: Number(38,0) ).
+1- Safer
What context do you see this default in? When generating a new workspace that translates from format X to SQL Server, or when manually adding writer feature types?
+26- Contributor
I would suggest in every location that FME now decides what datatype to use. So if the datatype is not predefined in the database (new writer or new featuretype) the default should be used.
The precision could be defined by the data, but I have experienced quite often that the precision is defined by the first x number of rows and is not sufficient for the complete dataset.
+22- Safer
Thanks for pointing out a very old default that is hardcoded in workbench. WIth time we are trying to make Workbench much smarter with data types in general, but in the very short term (2016.1) we will change this default to varchar which will be so much smarter on most modern systems.
+22- Safer
Being able to adjust the default is a great idea too, we'll think more deeply on that.
+21- Supporter
char(x) is the default when a string attribute value is calculated, it is from a web service, (maybe from CSV) and similar situations when FME just guesses the data type.
Yay, finally got 2016.1 two hours ago! There is varchar datatype, right, but why can't I delete the numer in the width field? Does it give the max number of characters? And what can I do if I don't want to give a max length? Thanks for your help...
I have small recomendation. If you plan to use Geoserver for data publishing I realy recommend to use nvarchar instead varchar. Varchar makes strange things in geoserver,mostly using in SLD or CQL filters...
Hello from the future in 2022 :) I am working with FME 2020.0 and I am running in to this issue. When I create a new workspace using the wizard from GTFS to SQL Server Non-Spatial it creates the basic workspace and when I check the (Static Schema) writer feature types I see only text as the 'Type' in the writers. I had thought this issue fixed due to the above conversation.
Could it be this issue is still hanging around on the computer or is there something else I need to do to get this to work? Appreciate any assistance!
+17- Safer
Hi @marcmpo ,
I reviewed the workspace and the document with the screenshots you shared.
From the screenshots you shared, I can see the data types are being mapped over as expected. There are attributes in the source data that have the data type as "text" so they are being mapped to "text" in the writer. But there are also other data types in the source data (eg. integer, time) that are being mapped to appropriate data types in the writer as well.
I hope this helps. If you're still needing further assistance, please submit a new question to our forum.
Thank you,
Andrea
Login to the community
No account yet? Create an account
An FME Account is required to contribute
LoginEnter your E-mail address. We'll send you an e-mail with instructions to reset your password.