To access a map service table as a standalone table it seems I have to specify a table container (map) in order to create an instance of the table e.g. StandaloneTableFactory.Instance.CreateStandaloneTable(url, map)
Is there a way I can get an instance of the map service table to query it without adding it to a map? This table is hosted in an ArcGIS Server Map Service. I want to avoid using the ArcGIS Rest Query endpoint directly.
For example in the Pro SDK I can open a geodatabase table using gdb.OpenDatase<Table>(name)
Basically I want to query some tables using .Search() which works fine, but I don't want them in the map.
If you publish a table as part of a feature service, you can use another layer on that service to get a Geodatabase pointer. Once you have that, you can use gdb.OpenDataset<Table>(name) as you would expect. The only thing to look out for is the feature service will change the name of the table that is exposed.
Thanks Rich, looks like we may have to reconsider our service types we publish in that case. Can you confirm this is the only way to get a Table instance from a web service table? We have an add-in with some functionality that queries some tables and runs off any data source type (fgdb, sde, and web service). Shame we can get a StandaloneTable instance but not a Table instance, guess that's a limitation of the mapservice capabilities?
Luke, I'm not sure I understand the question. You can get a Table object from a Geodatabase object using OpenDataset<Table>. This is true if the Geodatabase object comes from a file geodatabase, an enterprise client-server geodatabase or a feature service geodatabase. What am I missing?
It's ok I think you've answered my question, thanks Rich. The answer being that I need a feature service to get a geodatabase pointer; a map service isn't sufficient.
Could you tell me a bit more about the table name change in feature service geodatabases? Is this documented somewhere? Got this largely working but the naming is problematic!
Sorry for the delay.
By far the easiest way to open a table is to pass in the layer ID as a string to OpenDataset.
using (Table myTable = geodatabase.OpenDataset<Table>("2");
If you don't know the layer ID, the safest way is to get a list of the table definitions in the geodatabase. Loop through that list until you find one whose alias matches the alias of the table you wish to open. You can then get the changed name from that TableDefinition object. Consider this code:
Table GetTableFromAlias(Geodatabase geodatabase, String aliasName)
string tableName = "";
// Find the table name of the table whose alias matches
IReadOnlyList<TableDefinition> tableDefs = geodatabase.GetDefinitions<TableDefinition>();
foreach (TableDefinition tableDef in tableDefs)
if (tableDef.GetAliasName() == aliasName)
tableName = tableDef.GetName();
// Open the table that corresponds to this table name
if (tableName != "")
The issue is that my application doesn't know what the alias of the table is that i'm trying to find. It only knows the original source table name in fgdb/sde. Surely an alias should only be used for display purposes, should I really be using it to retieve tables? If I want to have functionality that runs off both local (fgdb/sde) and web (featureserver gdb) data sources, this means I have to query local sources using the original source table name, but query web sources using the alias or layer index? Or perhaps I should be using alias for both? I feel like i'm missing something here or misunderstanding. I don't understand why the table name would ever be changed unless I change it myself. Is original source name completely lost when published as a web service?
As an example, my original table name in the enterprise gdb is FLD_PROD. The alias is Field Production. The index of this table in the feature service is 1010. But the table name is changed to L1010Field_Production_ which is bizarre to say the least. Is there no way I can use the original FLD_PROD to get this table from the feature service?
I don’t think you’re missing anything and it sounds like you understand.
This is how we chose to implement it. Feature services tends to have a map-focused rather than database-focused viewpoint, and exposing the original tablenames is seen as exposing an unnecessary implementation detail.
Admittedly, this complicates an application like yours that tries to treat feature services and client-server databases in the same way.
Ok thanks Rich, I appreciate the help. It's a shame really, because the Pro SDK otherwise seems to treat the sources in much the same way once I have the geodatabase object, almost seemless.
Does seem like a strange design decision, if you ask me changing the table name is the unnecessary implementation detail!
My solution in this case will be to recode our add-in to query all tables by their alias instead regardless of data source (thanks for the snippet).