Latest Contributions by VinceAngelo

I've been UTF-8 compliant on my databases for 22+ years now. There really is no reason to go out of your way to make international names like "Côte d'Ivoire" give your front-end developers nightmares. - V ... View more

I've had good experiences with leveraging an SHA-1 hash of the non-key important data*, storing the hashes with the actual primary key in a parallel table.  Due to the nature of the data, I've sometimes converted the data to only a few significant digits, then hashed that (to enable "fuzzy matching", when 3.71 -> 3.72 or 3.68 is not significant, but 8.23 is). Recently I've stored the geometry and non-geometry hashes separately, and have even been able to match rows without a useful rowid key by inverting the hash dictionary spanning tens of millions of features, so that hashes could resolve feature matching at 85-97% accuracy. Unfortunately, I can't release my code without  approval. And in order to make this work , you need to  be really comfortable with endian integer and floating-pint storage representations. I can say the core code is a set of encoder functions (one for each supported type), which is stored as a bytearray sequence, that is fed into a core Python hashing function. Use of SHA-1 can generate safety warnings, but using it for hashing (not cryptographic) purposes is perfectly safe. - V --- *Unimportant data would include a URL that incorporates the primary key and another column, which could be recomputed (or changed at will) ... View more

You need to go back and review the documentation on versioning. Versions stay forever, until deleted. They also pin subsequent edits in the A/D tables, making the geodatabase less efficient. This is not something which should be ignored. If that initial set of edits in that version was just to prove it was possible, and never intended to be merged into the table, the version should be removed, and the state tree compressed, to eliminate the exact problems you're having now. Versioned editing is a process, with primary use cases designed to incorporate the edits as quickly and efficiently as possible. Coloring outside the lines of best practice can stress the implementation and result in suboptimal performance. - V ... View more

One simple heuristic: Use Create Fishnet (Data Management) to partition the space, then iterate the features, using them to Select Layer By Location, and compare the number of selected features. If fishnet cell size is, say, 20-50% larger than the usual subdivision area, missing subdivisions will stand out in the feature counts. From a computer vision standpoint: Symbolize the features with exceptionally wide line symbols, in two different primary or secondary colors with 50% transparency, then make a series of tiled images, and look for images (areas) where one color predominates. - V ... View more

Doug -- Views are, well, views. The geodatabase doesn't have the XML metadata from the original table(s)' columns, so it can't know what the aliases were. So it's not a matter of "dropping" them so much as never having had them. And if the view can't participate in geodatabase behaviors, it doesn't get the XML that permits aliases to exist. Note that nothing is ever "in the SDE". It's always been in the database, accessed through what was last called ArcSDE (but nowadays, it's all just ArcObjects). SDE is long gone. "There is no Dana, only Zuul." - V  ... View more

Please edit the question to place the code in a code block (click on "..." then "</>" in the second row of icons). Reading Python code without indention is nearly impossible. It's also nearly impossible to debug incomplete code (especially when there are TWO SearchCursor flavors [and arcpy.SearchCursor is deprecated, and should not be used in code written since 2013]). But you should know that nesting cursors is an antipattern, and the likely cause of your error. - V ... View more

The PostgreSQL team made a significant change at PG 12 that eliminated a hidden column that Esri was using as the primary key on the objectid allocation algorithm. I'm not sure you can make the leap from PG10 to PG15 just by doing a backup/restore, since all your "i-tables" are now invalid. If the tables aren't versioned, you might be better off exporting through file geodatabase, or just copying from the PG10 instance to the PG15 one (you can run both on the same box using different ports). Tech Support likely has better tools to work out the problem here. - Vince ... View more

You have corrupted geodatabase metadata. TLDR solution: Rename the table to a temporary name Create a dummy table (just objectid is enough) with the "existing" name Use ArcObjects (Pro UI or ArcPy) to delete the dummy table Rename the temp name back to original Register the no-longer "existing" table - V ... View more

Management Studio is a client to the SQL Server database, just like Pro, so it doesn't really have any role in enterprise geodatabase compatibility.  You don't state the database server version in use, so it's hard to determine compatibility, but that message seems to come from the database drivers, not from Esri components. Note that it's recommended to upgrade your clients to the intended Enterprise version before upgrading the ArcGIS Server/Portal components, so you really ought to be running ArcGIS Pro 3.4 with Enterprise 11.4. The software compatibility matrix is available in this FAQ topic. - V ... View more

Well, if you had used the sde schema, not sdo, and didn't register any user tables, then dropping the sde schema (including contents) could have been enough.  And if you can identify all the dbo tables that were added (most have 'sde_' or 'gdb_' prefixes), you might be able to pull this off (again, provided you didn't register any tables). Once you've registered a table with the geodatabase (with either sde or sdo model), the cleanup becomes significantly more complicated, and falling back to the last backup (Ryan's suggestion) makes good sense. - V ... View more

Branch versioning isn't just another flavor of database versioning. It has a specific set of use cases, all of which go through a services architecture endpoint.  So, it's not a property of the connection so much as a property of the service. I wouldn't expect ArcPy to be real useful here; this seems more in the domain of the ArcGIS API for Python (which is more Portal-centric). This Blog from 2019 might help clarify how what you're describing is the intended design of Branch Versioning. - V ... View more

First of all, it's important to point at that "SDE" no longer exists. The functionality of the product formerly known as "SDE", then "ArcSDE", has dissolved like ink into water within ArcGIS Enterprise functionality. The last dregs of "SDE" naming are the "sde" login that owns enterprise geodatabase metadata (in most environments), the ".sde"-suffixed file known as a "Enterprise Geodatabase Connection File" (or just "connection file") and the arcpy.ArcSDESQLExecute() function (that executes arbitrary SQL code as the connection user). The connection file UI widget has a specific functionality in Desktop interfaces (based on permissions), and there isn't any way to change that. If you know how to create login and group roles and GRANT access to tables, you know all that is necessary to get an approximation of what you are requesting here out of connection files. Doing it this way would be cumbersome, moderately hideous, and probably result in awful performance (burdening the database server with far more connections than is necessary) The only way you can filter tables like this is if you make your own UI component, fed by a JSON file or other config file. The particulars of implementing such a UI component would be better researched in an ArcObjects, Pro API, Python, or other programming interface forum, since this isn't really a data management issue so much as a custom UI one. - V ... View more

I've been using PostgreSQL/PostGIS with ArcGIS clients since at least PG 8.0, probably to PG 7.something_small. Desktop clients have supported direct write to even non-enabled PostgreSQL instances since  ArcGIS 10.4.1.  All the ArcGIS Pro releases have supported at least three PostgreSQL releases, sometimes as many as five. Instead of filing an enhancement request to do what the software already has done for two decades, you'd probably be better served by asking a specific question about your particular use case. Critical information includes: The exact PostgreSQL release The database name and table owner name The exact command you're using The exact error or other problem encountered It's not like there aren't some quirks to how PostgreSQL is supported, but it's not all that difficult to get full functionality, both with and without geodatabase enablement. - V ... View more

This isn't so much a "Data Management" question as it is a raster manipulation one. You might be better off looking in the Spatial Analyst, ArcGIS Pro, or Geoprocessing communities. - V ... View more

Rather than rewriting the whole dataset, and having to take the service offline to do so, you could amend your process to only UPDATE the changed records, INSERT the new records, and DELETE the no longer active ones. In one system where I did this, I'm able to complete UPDATE and INSERT operations in ten minutes, processing 100k of change messages (many of which are redundant) while the parent system takes three hours to make its changes using the "reload everything" procedure. For me, the key is to crunch the rows into a SHA-1 hash with a key (or compound key) associated with each row. Then after the changes in the parent occur, I pull the hash table into a Python dictionary, then scan the parent table, hashing each row. If the key exists in the dictionary, and the hash is equal, no change is necessary (and I delete the matching dictionary item). If the hash is different, I set the query row (and hash) aside into an update queue (and also delete the dictionary key). If the key isn't present, then the row goes into an insert queue (with hash). Once I'm done with input rows, any keys still in the dictionary become my deletion queue. Then the deletes are made from the table by key (and likewise from the hash table), updates are made to the child table (and the child's hash table in parallel), and the inserts are performed (to both table and hash). It depends on the data change frequency and volume whether I vacuum and rebuild indexes daily, weekly, or monthly. A service that I've deployed processes 100k-500k rows every 12 hours, performing 4k-10k updates and 3-50k inserts in 10-25 minutes (and has been doing so for half a decade now). I'm about to deploy another system like it, and it will process 26-30 million rows each month, with 1k-5k in combined U/I/Ds, in a hour or so (loading the full tables from scratch takes 6-8 hours, which is a lot of downtime for a 24x7 system). - V ... View more