Hi,
I am experiencing problems to Register table and/or view created in third-party SQL client (underlying DBMS is Oracle).
The register tool requires ObjectID field only for view which has to be integer:
To register a table, an ObjectID field is not compulsory.
In my view, I created a not null, no identical ObjectID field using a CAST( as integer) limited to 4 bytes (up to 10 digits) to comply with this technical issue:
https://support.esri.com/en/technical-article/000010398
The ObjectID field is matched to LONG in ArcGIS. It looks ok.
However, it always fails to register such table and/or view and I receive the "unexpected error... The view's registered base layer was not found." It does not make sense and I remembered registering table and/or view still recently. For info, I am the table and/or view Owner.
On the other hand, if I copy & paste this table in the ESRI environment (Catalog), it automatically registers (meaning the table is valid for registration).
Any help really appreciated.
Solved! Go to Solution.
Hi,
Good news, the upgrade to ArcGIS Pro 2.9 solved the issue
The Register with Geodatabase geoprocessing tool can now register views made from scratch from third-party client, mashed from other tables stored in underlying RDBMS and spatially enabled with SDE function.
I even noticed the tool faster in Pro. Excellent
Hi Vincent,
Did you find a solution to solve your issue ? We are having the same problem.
Thanks
Hi, not solved yet. I intend to do some more testing in the next few weeks and I will post here if I find anything
Hi,
Earlier this year, I posted above about issues to Register table and/or view created in third-party SQL client (underlying DBMS is Oracle). I looked again in the problem and found a workaround.
To make it simple, the Register with Geodatabase tool in ArcGIS Pro (running 2.8.2) is not working. This seems unbelievable but it is the case, either with:
- right-click in the table/view to register > Manage > Register with Geodatabase
- Register with Geodatabase geoprocessing tool in Data Managements Tools > Geodatabase Administration > Register with Geodatabase
- Register with Geodatabase at Python command line
To overcome this issue, I simply step back to ArcGIS Desktop 10.5.1 and registered my tables or views with no problems using the Register with Geodatabase geoprocessing tool ... Please ESRI, can you confirm this bug and/or fix it in future releases of ArcGIS Pro.
Finally, in ArcGIS Pro, if copy & paste a table in the Enterprise Geodatabase (in Catalog), it does register the copied table automatically (meaning the table is valid for registration). This is not handy though. In addition, if using Create Database View in geoprocessing with a SQL statment based on a table, the Register with Geodatabase geoprocessing tool works on this view.
Hi,
I reply to 'myself' because I believe this might help other ArcGIS Pro users.
I ran again the Register with Geodatabase geoprocessing tool in ArcGIS Pro and noticed the following message:
"The view's registered base layer was not found.
Failed to execute (RegisterWithGeodatabase)."
I found it interesting because the Register with Geodatabase geoprocessing tool in ArcGIS Pro 2.8.3 works ONLY if the view being registered reference another table in the Enterprise GDB already registered.
The Register with Geodatabase geoprocessing tool in ArcGIS Desktop 10.5.1 is more forgiving and smarter as you can register views, made from scratch, I mean mashing others tables stored in underlying RDBMS, and spatially enabled with SDE function. This does not work with the Register with Geodatabase geoprocessing tool in ArcGIS Pro.
Please ESRI, fix and improve (just as in ArcGIS Desktop 10.5.1) this geoprocessing tool for future releases of ArcGIS Pro.
Hi,
Good news, the upgrade to ArcGIS Pro 2.9 solved the issue
The Register with Geodatabase geoprocessing tool can now register views made from scratch from third-party client, mashed from other tables stored in underlying RDBMS and spatially enabled with SDE function.
I even noticed the tool faster in Pro. Excellent
Thank you, @VincentLaunstorfer, for your continued updates on this issue!