Latest Contributions by VinceAngelo

You really need to `print` your SQL and try running it in a SQL browser, since it's probably not doing the right type casting (and therefore not returning rows). - V ... View more

This is more of a "Want" problem -- If they don't want to migrate, then no obviously superior solution will ever be acceptable. - V ... View more

The shapefile limit on character width (254) means you can only reliably store ~10 vertices in a dBase file. Rectangles and hexagons are possible; countries, states, counties, and even circles are not. Zipcodes would need to be dumped to CSV or processed in memory, because they could not possibly be stored in a shapefile. - V ... View more

"SDE" hasn't been the product name for a long, long time, and in fact, ArcSDE no longer exists either. The current term of art is "enterprise geodatabase". All you need to connect to a database is the connection DLL(s) of the database vendor. If the data has been stored in native geometry, and the database release is compatible with the Esri release (there are a number of Pro versions, each with a list of supported database releases), then "migration" should not be necessary -- a "Query Layer" should see the table contents immediately. Editing features in an enterprise database requires ArcGIS Server licensing and "enablement" of the database for enterprise support. - V ... View more

If appending large numbers of rows to existing feature classes, make sure you drop the spatial and non-critical attribute indexes before starting the Append -- This could make an order of magnitude difference in load performance. You'll need to build those indexes afterwards. The threshold for Append vs. DropIndex/Append/BuildIndex is only 10,000 features. ... View more

Best practice is the same across RDBMS platforms, utilizing the "Least Privileges" principle: Create the table owned by a close-held login account (e.g., "HIGHWAY_DEPT") Create ROLEs for appropriate access (e.g., "HIGHWAY_BROWSE","HIGHWAY_EDITOR") GRANT appropriate role access to the the table ("GRANT select ON highway_dept.streets TO highway_browse") Create logins for each staff member Create logins for each discrete web application (e.g., "web_app1") -- NEVER use the data owner to publish data!! GRANT appropriate roles to each staff member's login ("GRANT highway_editor TO vinny_boombatz") GRANT appropriate roles to each staff member's login ("GRANT highway_browse TO web_app1") Enable EDITOR_TRACKING on each table (as the owner) I guess there needs to be one other: Sanction any user who releases a password (their own, or the owner login) outside the those with approved access Depending on the organization, data can be developed using the personal login/schema, and once deemed "ready" (by review board, common acclaim, or personal attestation), the "admin" can recreate the table and contents with the "department" login and grant appropriate access. Note: I do this myself, even if I'm the only data team member, so web services can't see anything that isn't "ready". If the table definitions are dynamic, I'll number the tables ("streets_t1") and use views to expose them ("streets_v10").  If a new column is necessary, I'll expose it, in necessary order, via "streets_v11". Major changes get a version kick ("streets_t2" + "streets_v20"). If you're using the Wild West approach now, it can take some time to adjust, but the benefits to implementing rational access only increase as the project team adds members. - V ... View more

The model used to construct UUIDs makes for low likelihood of collisions, though it's higher (but still very unlikely) if you use several different generators (e.g., Oracle and PostgreSQL and Python and Java).  Unfortunately, that very uniqueness makes UUIDs an awful column to drive joins upon (they're modelled as 38-char strings which fragment the available key space). 64-bit integers are coming to Pro in the near future; these would also not be limited to "only" a 4-billion value key space (as 32-bit integers), but would have better join performance for sequential features. - V ... View more

Yes, I mean create an empty table (not yet registered), and populate it via SQL (then register it). - V ... View more

The sde schema shouldn't be involved at all in any cross-DBMS geodatabase migration, only the table owner(s) at first. I actually prefer to use SQL to define the tables *exactly* as desired, then Append from the source or even use FeatureClassToFeatureClass to generate a near clone, and populate the contents of the new table(s) via INSERT INTO newtableN(columnlist) SELECT columnlist FROM temptableN.  This latter solution allows flexibility to restructure the table, or optimize physical order via an ORDER BY (or both).  Of course, any versioned edits would be need to be reconciled and posted before starting transfer, and the feature classes only versioned in the target database after confirming successful transfer. I recently did this with 120 million rows across a score of tables, optimizing the partitioning and adding timestamp columns for insert and update. I used Python to transfer the data, and added a parallel table with a SHA-1 hash to fingerprint the new contents, then compared the hash with a hash of the source data to confirm successful transfer. - V ... View more

ID assignment is quirky, but that's an artifact of needing to work for both a hundred features and a hundred million. If you can deemphasize the significance of the OBJECTID in the eyes of users, it's probably worth the effort. - V ... View more

Some more details would be useful: Which RDBMS is being used for the data source? Has it been restarted since the last features were loaded? In general, this is expected behavior.  Sequence-based ID assignment is not very efficient for bulk loading, so ArcGIS uses a sequence (or sequence-like structure) to allocate blocks of IDs. The size of the block is dependent on the ArcGIS release and the RDBMS. In theory, they would be equivalent, but there are use cases where the remainder of the IDs within the block are not allocated completely. And, of course, multiple simultaneous loaders will insert using different ID ranges, so it can be difficult to determine missing ranges. In practice it doesn't much matter, since the allocated IDs should only really be used by the geodatabase to maintain uniqueness, not for any other purpose. - V ... View more

More information is needed: What exact RDBMS are you using? (If it's changed recently, we need both old and new versions) What is the exact release of the geodatabase?  ("10.x something" encompasses most databases produced in the past decade) What is the exact release of the GIS client used to connect to the database? Has anything changed on the system? - V ... View more

Huzzah, huzzah! - V ... View more