Latest Contributions by VinceAngelo

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

Since this is a Professional level exam, it's more about experience and familiarity than memorization. The Qualifications and Skills Measured lists should be sufficient to review less actively used aspects of the material. There were sample questions in previous iterations, but this most recent exam doesn't seem to have any. - V ... View more

Whenever something new comes up, the question to ask is "What changed?" The error message is indicating login/schema issues, so in this case, what changed in the database?  Did someone alter the login/schema mappings? Has there been a database rev update?\ - V ... View more

The definition of "unused" needs scope.  They were all used at least once. It would be possible to scan a number of map projects to inventory the "used" tables, but much more difficult to scan for all scripts or SQL functions/triggers that exploit "unused" data to manifest "used" data. - V  ... View more