Latest Contributions by RyanUthoff

If you're okay with using Python outside of ArcPy, then I will give you a couple of scripts that can be used to determine the tables and views. Of course, you'll still need to modify the scripts to forward them to your views/items DB, but it should at least give you a starting point. You'd still be able to run this as a script tool in ArcGIS Pro. It uses Python to directly connect to a MS SQL database. #Output Tables import pyodbc def list_tables_mssql(server, database, username, password): try: # Connection string conn_str = ( f"DRIVER={{ODBC Driver 17 for SQL Server}};" f"SERVER={server};" f"DATABASE={database};" f"UID={username};" f"PWD={password}" ) # Connect to SQL Server conn = pyodbc.connect(conn_str) cursor = conn.cursor() # Query to get all user-defined tables cursor.execute(""" SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'BASE TABLE' """) tables = cursor.fetchall() if tables: print("Tables in the SQL Server database:") for schema, name in tables: print(f" - {schema}.{name}") else: print("No tables found in the database.") except pyodbc.Error as e: print(f"SQL Server error: {e}") finally: if conn: conn.close() # Example usage if __name__ == "__main__": list_tables_mssql( server="localhost\\SQLEXPRESS", database="YourDatabaseName", username="YourUsername", password="YourPassword" )      #Output Views import pyodbc def list_views_mssql(server, database, username, password): try: # Connection string conn_str = ( f"DRIVER={{ODBC Driver 17 for SQL Server}};" f"SERVER={server};" f"DATABASE={database};" f"UID={username};" f"PWD={password}" ) # Connect to the SQL Server conn = pyodbc.connect(conn_str) cursor = conn.cursor() # Query to get all views in the database cursor.execute(""" SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS """) views = cursor.fetchall() if views: print("Views in the SQL Server database:") for schema, name in views: print(f" - {schema}.{name}") else: print("No views found in the database.") except pyodbc.Error as e: print(f"SQL Server error: {e}") finally: if conn: conn.close() # Example usage if __name__ == "__main__": list_views_mssql( server="localhost\\SQLEXPRESS", database="YourDatabaseName", username="YourUsername", password="YourPassword" )   ... View more

This Esri documentation has some really good information on what settings are inherited in the view from the hosted feature layer that can and cannot be changed on the view. Per the documentation, edit settings can be configured independently on the views from the hosted feature layers they are created from. Meaning that you should be able to allow editing on the view, with it still disabled on the hosted feature layer. (Note that some additional edit settings, such as editor tracking, must be made at the hosted feature layer level. But the enable/disable editing setting itself can be changed independently on the view). This is something that I just tested with my own hosted feature layer/view in AGOL and it works fine for me. Editing is disabled in the hosted feature layer, but enabled on the view and I can add new data as well as edit existing data. Your "applyedits" response in the network traffic indicates a different problem. It appears that it is trying to add a record with the same key, which is not possible to do. For example, if ObjectID is your key field and you have a record with an ObjectID of 1. And then you try to add a new record with an ObjectID of 1, it will fail because a key with that value already exists. I've never really heard of that being a problem in AGOL though. If it's possible, it might be worth trying to enable editing on your hosted feature layer and see if you are able to add new records to it, or if you receive the same error. If you don't receive any errors, it might be worth trying to delete and re-create the view again. And if you do receive errors in the feature layer itself, then I think you have a different problem that needs to be resolved. ... View more

Normally there are connections to the DB with one instance running, even if no one is actually using the feature service. You could set the minimum number of instances to zero. But the downside is that your users will have roughly an extra 30 second delay for that feature service to come online the first time it is used after being at zero instances. I suppose the more "elegant" way of handling it would be to stop your feature service as a part of your FME process. Then you wouldn't have to worry about the feature service causing any locks. This support article says how you can do it through the Python API, which you could integrate into your FME processs. You could configure it to run the Python to stop the services before the FME process runs, then run the Python again afterwards to start the services. ... View more