I have a sql server table that I do not own but have full permission on.
I can setup a GEODATABASE_SDE Reader and read it no problem the table qualifier is "abc\\username"
When I try to setup a writer for it the Table Qualifier gets set to _abc_username_
When I try to write to it I get an error message stating
Geodatabase Writer: Feature Class or Table '_abc_username_.table_nm' must exist when Table Handling is set to 'Use Existing'
Unfortunately using FME2018.
@tgroeneveld The Feature Dataset is only needed when your creating the Feature Class (Table Handling = "Create If Needed" OR "Drop & Create")
If you are creating the feature class, then try setting the Feature Dataset in the Table Creation Parameters panel.
Wasn't using the Feature Dataset.
I add a writer by selecting a table from a list. The table I'm picking is not owned by me but I have edit permission on it.
The "abc\\username" gets changed to _abc_username
When it trys to write to the table it can't find it and throws an error.
Interesting I can add a reader and it retains the table qualifier as "abc\\username", and is able to read the data.
@tgroeneveld thanks for the clarification. It is the table qualifier and not the feature dataset. I've reproduced the issue. There isn't a work around as far as I can tell.
Check that you do indeed need the table qualifier. If this is the only feature class with this name then you might be able to read it without the qualifier.
Thanks @Mark Stoakes .
Table Qualifier is needed to find the table.
The account that owned the table was a network account (operating system authentication). Switched that over so the table was owned by a database account. The writer can now find the object as the table qualifier no longer has '\\' in it. It is just the username of the owner.
Thanks @Mark Stoakes .
Table Qualifier is needed to find the table.
The account that owned the table was a network account (operating system authentication). Switched that over so the table was owned by a database account. The writer can now find the object as the table qualifier no longer has '\\' in it. It is just the username of the owner.
@tgroeneveld Thanks for letting us know that you found a workaround. We will try and fix this in a future release.
Hi. I also stumbled upon this today.
Solved it by publishing the Table qualifier as a parameter. Then I was able to set the published parameter to [xxx\\yyy]. 🙂
But I consider this being a bug...so I reported it.
Hi. I also stumbled upon this today.
Solved it by publishing the Table qualifier as a parameter. Then I was able to set the published parameter to [xxx\\yyy]. 🙂
But I consider this being a bug...so I reported it.
Thanks. Never thought about using parameters as possible work around.
Happy to share any findings!
It is still a hassle to import featuretypes from tables having a \\ in its Table qualifier, so I'm reporting this as a general bug in DB-reading/writing (same problem in MSSQL...).
Happy to share any findings!
It is still a hassle to import featuretypes from tables having a \\ in its Table qualifier, so I'm reporting this as a general bug in DB-reading/writing (same problem in MSSQL...).
Tracking these in FMEENGINE-67635 (Geodatabase) and FMEENGINE-64873 (MS SQL Server)
@Mark Stoakes - Any update on this issue please? I was able to reproduce this in 2021.1 (Build no: 21607)
@fmeuser_gc Sorry - this has not been addressed as of FME 2022
As I've inherited some of @nissedahlsten 's workspaces on a project, I've found that the trick with publishing the table qualifier as a published parameter only works when publishing workspaces from FME version 2020.2 (Build 20787) to FME Server version 2021.2 (Build 21816).
It does not work when publishing the very same workspace from FME version 2021.2 (Build 21816) to FME Server version 2021.2 (Build 21816). In this case the FME Server replaces the brackets and backslash to underscores.
