Latest Contributions by VinceAngelo

Never, never, NEVER, NEVER publish as the data owner.  This is a HUGE security risk.  Just don't do it. This is a Security Modeling 101 issue. The principle here is "minimum necessary privilege". The owner has way too much access to the table. Instead, create one or more browse users, and roles for each kind of access, and grant access to the tables to the roles, and grant roles to users. Publish data with the user holding the least possible access to make effective use the data. If some apps need UPDATE, but others don't, publish with different publishing users (e.g., "app1_pub" & "app2_pub"), only granting the minimum necessary to each.  - V ... View more

That's not a supported combination.  It might work, or it might spawn a small black hole which consumes the data center. I wouldn't hold my breath for either of these outcomes for ArcGIS 11.0. - V ... View more

Your first step should be to search on "arcgis postgresql requirements" and look to see if the database is supported (PG 16 isn't supported at 11.4.0, much less 11.0). I haven't tuned an RDBMS in at least a decade, possibly two, so I doubt this is a priority. - V ... View more

Why do you need the MV registered? Is it going to participate in geodatabase behavior?  If you just want to render from it, making a Query Layer of the unregistered table would likely suffice. Conflicts that could be created between the ArcSDE metadata and geodatabase metadata was the reason the ancient command-line utilities were deprecated long, long, ago. Even if you could make a 10.2.2 sdetable function, you could only harm the integrity of a modern geodatabase. Registration of views is a relatively new feature. If you haven't installed a service pack to 3.2, you probably ought to, at least 3.2.1, but the 3.2.4 terminal release is likely to be better. - V ... View more

The length and area columns are often wrong, or useless, so it's quite possible you won't find what you're looking for. "Internally calculated Cartesian value that should not be trusted for any real-world purpose" would suffice for both length and area. - V ... View more

Dissolving millions of features to a few hundred is a nightmare case. You didn't provide most of the requested information necessary to help. Having corrupt geometries before the Dissolve would put a knife into the back of the post-Dissolve topology; that might not be recoverable without significant data loss.  - V ... View more

Even 200k rows can be slow if they're wide enough.  You should certainly have an index on the query column, but first priority is to copy the FGDB directory to local disk. - V ... View more

There are a bunch of things here: 200m rows is an order of magnitude higher than I would feel comfortable using for file geodatabase (yeah, it functions, but a real database would function much better). Shared folders are performance death for file geodatabase, with a minimum 2x cost accessing a local network share Full-table-scan queries are performance poison relational databases with very large tables.  If it's important enough to do a query, it's important enough to build an index. You should not be using an OR when you could use an IN: rel_objectid in (26,19804) Remember that FGDB doesn't have an RDBMS optimizer, so you should always pitch softballs for queries. - V ... View more

There's really gobs of options here. I worked one project where Survey 123 was used to populate attributes for imagery, and database triggers and batch geoprocessing scripts handled it from there. You can also have a true "not ArcGIS" solution with a tiny web form that populates a database and geoprocessing steps take it from there.  If Excel is your thing, completing metadata in a spreadsheet and dropping that in a folder or S3 bucket to generate further processing is an option. - V ... View more

At some point, you need to leave 10.8.x behind. I'm an extreme late adopter, and I've been using Pro exclusively for years, even for hobby projects. Python 3 is worth the transition cost, and clinging to an unsupported platform is just no fun. - V ... View more

You may need to time the upgrade process carefully, because I don't think it's possible to upgrade a 10.4 geodatabase directly to 10.9.  You probably need to upgrade to 10.7 geodatabase first, then upgrade the SQL Server, then upgrade the geodatabase to 10.9.  Even 10.9 is a couple of revs off current, so you might have issues using a modern Pro release with a 10.9 geodatabase. - V ... View more

Few features with extraordinary numbers of vertices is actually on the other side of the diminishing returns curve, especially if the extents are large, relative to the overall layer extent. We'd need a lot more information: The exact numbers of features (and geometry type) The number of vertices and/or parts  The storage format (shapefile, file geodatabase, enterprise geodatabase, and if EGDB, which RDBMS) The average ratio of the extents to the overall layer extent An indication of the extent at which the resulting data is being rendered (relative to overall extent). - V ... View more

Tim -- Let's just say I would never try this. I do know the underlying API is capable, because in the distant past (e.g. 8.2? 9.0?), a colleague used my 'asc2sde' utility to load 680m rows in under 18 hours, into Oracle, SQL Server, and PostgreSQL (three different servers, concurrently). Note that this was before native geometry was the usual solution. That said, what does Append really get you here that raw SQL wouldn't?  I'd be tempted to chunk the data into 5-10m SQL statements, then execute them in a native CLI utility (SQL*Plus/sqlcmd/psql) , but I'd also want to benchmark using a DA SearchCursor with a collection of DA InsertCursor commands, and  using a collection of arcpy.ArcSDESQLExecute cursors with INSERT SQL statements (with a del cursor every few million rows).  If I were an FME guy, I'd also benchmark that, all  across 50m rows, then use the one that presented the least difficulties. I'd also strongly consider just leaving the data where it is, and adding a PostGIS geometry to it and moving forward with my project. - V ... View more