Ok, here is the senario:
Overall, Im not sure I am thinking about the process in the correct way. Any ideas anyone?
Do you need to retain the relationship of the join or do you just need to transfer the attributes once? I'd just add the join then export to a new feature class and publish that. It's probably erroring because the server can't see or publish the xls.
We had a similar situation in the past, joining parcel data to outside assessment data. What we did:
The resulting service will show the fields like they were "baked in", so to speak. End users will have no way of knowing that the source of the data is actually multiple tables. Since the query layer references the database, as the underlying tables are updated, so too will the query layer update.
Josh, thanks to the insight. I believe this is the process that I need. The current issue is that when importing the table (csv) into the Enterprise GDB, an Object-id field is created. This seems to casue a duplicated field. Unfortunatly, I dont seem to be able to delete the ObjectID field in the new table. Ay ideas?
It's true, there will be an objectID field. But if you're publishing the service from a query, you only need to include one unique identifier. You can leave the objectID on the imported table for the database's own internal management, but the query layer need not expose that field.
SELECT a.objectid, a.some_field, b.another_field, b.etcetera, a.shape FROM first_table a LEFT JOIN second_table b ON a.shared_field = b.shared_field