Hello there
we have a simple WS GeoDb reader and SQL server writer and we are only renaming 2 attributes as shown
but the table created on SQL still keep the same name as the reader ignoring the renamer transformer
is there any reason why?
Solved
Dynamic output SQL server , attribute renamer not working
+11- Contributor
Best answer by takashi
Hi @boubcher,
- In your settings, the destination schema will be derived from the source geodatabase schema definition.
- The AttributeRenamer just renames attributes which are contained by each feature, it won't change destination schema.
- If you need to modify the destination schema, you will have to derive schema from other resource (external dataset, lookup table, list attribute, etc.) which contains your desired schema. See the Tutorial: Dynamic Workflows to learn more.
- However, in some cases, you can partially modify the destination schema through the writer feature type properties.
- In your case, the following workflow and writer feature type configuration might help you.
+41- Evangelist
Hi @boubcher
I simulated here to read a Geodatabase, but its works similar.
After the transformer AttributeRenamer I think you could use the transformer AttributeExposer and exponse the two old Attributes:
Shape_Area
Shape_Length
In the Writer - tab User Attributes - Please write the two new attributes but let the option Attribute Definition in Dynamic.
It was worked for me.
Thanks,
Danilo
+11- Contributor
@Danilo
Thanks for your response
it did work but by only selecting Automatic in the Attributes
userattributes-1.png
userattributes-2.png
then back to Dynamic
userattributes-3.png
but in the database we are getting duplication of both attribute, I have no idea why is that
userattributes-4.png
+19- Contributor
- Best Answer
Hi @boubcher,
- In your settings, the destination schema will be derived from the source geodatabase schema definition.
- The AttributeRenamer just renames attributes which are contained by each feature, it won't change destination schema.
- If you need to modify the destination schema, you will have to derive schema from other resource (external dataset, lookup table, list attribute, etc.) which contains your desired schema. See the Tutorial: Dynamic Workflows to learn more.
- However, in some cases, you can partially modify the destination schema through the writer feature type properties.
- In your case, the following workflow and writer feature type configuration might help you.
+11- Contributor
takashi wrote:
Hi @boubcher,
- In your settings, the destination schema will be derived from the source geodatabase schema definition.
- The AttributeRenamer just renames attributes which are contained by each feature, it won't change destination schema.
- If you need to modify the destination schema, you will have to derive schema from other resource (external dataset, lookup table, list attribute, etc.) which contains your desired schema. See the Tutorial: Dynamic Workflows to learn more.
- However, in some cases, you can partially modify the destination schema through the writer feature type properties.
- In your case, the following workflow and writer feature type configuration might help you.
@takashi
its works
is there a way we could specify a specific schema name to write to, by default its writing to Dbo , I do have a mapping of each table and it corresponding schema name in Sqlserver
+19- Contributor
boubcher wrote:
@takashi
its works
is there a way we could specify a specific schema name to write to, by default its writing to Dbo , I do have a mapping of each table and it corresponding schema name in Sqlserver
+41- Evangelist
boubcher wrote:
@Danilo
Thanks for your response
it did work but by only selecting Automatic in the Attributes
userattributes-1.png
userattributes-2.png
then back to Dynamic
userattributes-3.png
but in the database we are getting duplication of both attribute, I have no idea why is that
userattributes-4.png
I'm sorry. I checked now your answer because we have difference time. But, I'm happy that @takashi
+11- Contributor
takashi wrote:
Hi @boubcher,
- In your settings, the destination schema will be derived from the source geodatabase schema definition.
- The AttributeRenamer just renames attributes which are contained by each feature, it won't change destination schema.
- If you need to modify the destination schema, you will have to derive schema from other resource (external dataset, lookup table, list attribute, etc.) which contains your desired schema. See the Tutorial: Dynamic Workflows to learn more.
- However, in some cases, you can partially modify the destination schema through the writer feature type properties.
- In your case, the following workflow and writer feature type configuration might help you.
I did see the article before the question but its shows a fixed schema for the entire table
"(schema_name.@Value(fme_feature_type)"
in our case, we have for each feature type ( table ) a different schema as per the excel
schema-table-relation.png
+19- Contributor
takashi wrote:
Hi @boubcher,
- In your settings, the destination schema will be derived from the source geodatabase schema definition.
- The AttributeRenamer just renames attributes which are contained by each feature, it won't change destination schema.
- If you need to modify the destination schema, you will have to derive schema from other resource (external dataset, lookup table, list attribute, etc.) which contains your desired schema. See the Tutorial: Dynamic Workflows to learn more.
However, in some cases, you can partially modify the destination schema through the writer feature type properties.- In your case, the following workflow and writer feature type configuration might help you.
@Value(table_schema).@Value(table_name)- Contributor
takashi wrote:
Hi @boubcher,
- In your settings, the destination schema will be derived from the source geodatabase schema definition.
- The AttributeRenamer just renames attributes which are contained by each feature, it won't change destination schema.
- If you need to modify the destination schema, you will have to derive schema from other resource (external dataset, lookup table, list attribute, etc.) which contains your desired schema. See the Tutorial: Dynamic Workflows to learn more.
- However, in some cases, you can partially modify the destination schema through the writer feature type properties.
- In your case, the following workflow and writer feature type configuration might help you.
thanks so Much, I did use the feature merger to merge with the excel containing the schema name and the feature type name, and its working.
no the new attribute we created is giving an error ( Existing table for feature type `Adminstrative_Boundary.City_Boundary' does not have attribute with name `New_attribute'.)
during the process, we are looking to add the same attribute to all tables
+19- Contributor
takashi wrote:
Hi @boubcher,
- In your settings, the destination schema will be derived from the source geodatabase schema definition.
- The AttributeRenamer just renames attributes which are contained by each feature, it won't change destination schema.
- If you need to modify the destination schema, you will have to derive schema from other resource (external dataset, lookup table, list attribute, etc.) which contains your desired schema. See the Tutorial: Dynamic Workflows to learn more.
- However, in some cases, you can partially modify the destination schema through the writer feature type properties.
- In your case, the following workflow and writer feature type configuration might help you.
If you are going to create a new table by running the workspace, just drop the existing table beforehand.
If you have to keep records which are stored in the existing table, you will have to add a column to the table with an appropriate SQL statement beforehand.
+11- Contributor
takashi wrote:
Hi @boubcher,
- In your settings, the destination schema will be derived from the source geodatabase schema definition.
- The AttributeRenamer just renames attributes which are contained by each feature, it won't change destination schema.
- If you need to modify the destination schema, you will have to derive schema from other resource (external dataset, lookup table, list attribute, etc.) which contains your desired schema. See the Tutorial: Dynamic Workflows to learn more.
- However, in some cases, you can partially modify the destination schema through the writer feature type properties.
- In your case, the following workflow and writer feature type configuration might help you.
Thanks So Much working Now and did drop all tables and start over.
I think we should add all those cases to the Tutorial :)
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.