Why does arcpy.RebuildIndexes_management try and rebuild indexes on view?

868
7
12-23-2019 08:16 AM
Arne_Gelfert
Occasional Contributor III

I have an SDE maintenance script that has been working flawlessly on a number databases. I recently added another DB to my maintenance list, and for this one, the script bombs during the "arcpy.RebuildIndexes_management" step. The error is:

Could not rebuild indexes for dataset MYDB.dbo.myunsuspectingdatabaseView.[Operation Failed]

It fails when encountering a view!

Any idea under which circumstances that would happen? I have lots of views in my databases. While names don't always clearly indicate what's view (and I certainly wasn't the one to create them all), they can always be identified in SSMS under "view" or by the lower case "dbo" schema identifier (SQL Server). I have not run into this problem with views in any other database.

Any idea what might be going on here? I suppose I could create some sort of exclusion list and skip these objects but I'd like to understand what the problem is.

0 Kudos
7 Replies
George_Thompson
Esri Frequent Contributor

When you run it on other DB's are you running on DBO or SDE also?

--- George T.
0 Kudos
Arne_Gelfert
Occasional Contributor III

Everything in the script and about the other databases is the same, including DBO. The only thing that changes is the SDE connection file the script uses to connect.

0 Kudos
George_Thompson
Esri Frequent Contributor

Ok, that is weird. I have not seen that happen before. You may want to reach out to tech support on this.

--- George T.
0 Kudos
Arne_Gelfert
Occasional Contributor III

My suspicion first was that something didn't get registered correctly with GDB. I ran into that last week. Things that get created and registered, then deleted using non ArcGIS tools. Figured this was maybe some kind of orphaned object. But I can't imagine why it would even look at something that's a view. I'll search some more through forums. Really not a major issue if i can figure out how to skip that "bad" ones. 

0 Kudos
Arne_Gelfert
Occasional Contributor III

Wanted to provide an update on this:

I believe the issue was caused by trying to create/register spatial views in a SDE database of version 10.2. This is a little used database that apparently was never update. Others are all 10.5.From this thread  understand that there was some changes from pre-10.5. Why this would have caused views to end up in [SDE_table_registry], I don't understand but that's what tripped up my maintenance script when trying to rebuild/refresh indexes.

I haven't actually had time to update the GDB, I'll add a note about what that does. 

0 Kudos
MarcoBoeringa
MVP Regular Contributor

A bit of a side step, but there is also the concept of a "materialized view", which are views that reside on disk like a normal table, and that can be indexed as an ordinary table (at least in PostgreSQL which I am using, but I guess this is no different in SQL Server).

So it would not be entirely surprising for the tool to attempt re-indexing a (materialized) view.

0 Kudos
Arne_Gelfert
Occasional Contributor III

Yes, good point, Marco - familiar with materialized views or indexed views. However, I don't know how the arcpy reindex method is supposed to treat such indexes. In my case, there are no indexes associated with these views, at least none I can discern in SSMS.

0 Kudos