Latest Contributions by VinceAngelo

Shapefile and file geodatabase are very different formats. The only thing the FileGDB API has in common with shapefile is the geometry format used for geometry transfer (and that was done for simplicity -- FGDB doesn't use that format natively).  ArcGIS is certainly capable of creating shapefiles, but this is the wrong community for researching that on Android platforms. - V ... View more

The file geodatabase API Community is https://community.esri.com/t5/file-geodatabase-api/ct-p/file-geodatabase-api   ... View more

No, there is no "original database" for file geodatabase. It was created as a replacement for the Access-based "personal geodatabase" and as a lesser-complexity sibling of enterprise geodatabases. It is NOT based on any database (and if you look at the implentation, you can see the Esri VFILE lineage with INFO flair).. - V BTW: "inaccessible outside of ArcObjects" is not quite accurate, since the FileGDB API provides third-party access. ... View more

All ArcGIS clients have the capability to connect to databases (when the client library is present).  The list of supported column types in a Query Layer or Query Table should be the same as with an enabled geodatabase, but the geodatabase does provide hints on mapping NUMBER to fixed datatypes (short, int, float, double). So the real question, not provided in your post, is the data types of the columns (e.g., sqlplus DESCRIBE output). To me, "Data error" means an unexpected type mapping.  It could also be an overflow issue, like when a NUMBER(10) has a value in excess of 2^31-1 (2.14B), so first off is types, then you need to look at values. - V ... View more

That's nearly like asking what words and phrases are available in a thesaurus. Are you really looking for a comprehensive list, or something specific? - V ... View more

When you state that you have "~90 SDE Geodatabases", does that mean you have ~90 PostgreSQL databases? That would be quite a few. While the migration procedure is basic enough, migrating a half-terabyte to the cloud is not a trivial undertaking. Have you benchmarked performance, and/or plan to move the compute resources (Enterprise components) to the same cloud? Keep in mind that database latency is increased when using on-premise applications with remote/cloud databases -- I had a PG RDS migration delayed by more than a year until network infrastructure could support adequate bandwidth to the RDS mission, after initial benchmarking showed a 90-minute publishing export process took 4-6 days from the RDS host. You might want to look at migrating the SDE.ST_GEOMETRY columns to PostGIS Geometry in the on-premise instance, so that the migration will be a simple pg_dump/pg_restore.  But note that pg_dump corrupts PG 11 enterprise geodatabase datasets, because of the deprecation of WITH OIDS=TRUE (used in iN tables).  From that regard, you might be better off standing up PG12 or PG13 in the target instance (after making sure your other Esri tools are compatible with 12/13) To summarize: 90 databases/500Gb is a huge migration Beware of increased latency in an off-premise database (unless you also move the data operation servers into the same/nearby servers) PG 11 is now the eldest supported database. PG 11-PG 11 migration via database tools is risky, and in situ enterprise geodatabase upgrade from PG 11 to PG 12/13 is not supported. Consider migrating to PostGIS geometry before migration, then going directly to the most recent release your Esri stack can support using database tools. Good luck. - V ... View more

Note that, while the PostgreSQL server software is free, the hardware on which it resides (or the RDS which exposes it) is not. Nor is the labor of a professional DBA (or the training to become a defacto DBA). So just because the database is "free" in the tenets of "free software" doesn't mean it comes without cost. - V ... View more

Enterprise geodatabases are stored in, not "connected to" vendor databases.  The distinction is significant, because it indicates how to locate the issue -- via the SQL client.  While there is "SDE data", it only exists in the sde/dbo schema metadata tables. All the other data is user data. One way to identify which column in your SQL is problematic is to reduce the complexity of the SQL command until it does not fail, then add columns again until it does. There are likely to be database vendor-specific solutions involving error logs for tracking down SQL errors.  If the SQL is being executed in an arcpy.ArcSDESQLExecute cursor, and additional details are being hidden, you can print the SQL before executing it, then use that SQL in a client window. A leading candidate for SQL problems are columns which are managed by a domain (you see a different value in the Desktop or Server interface than is stored in the database), though it seems less likely for this particular error message. - V ... View more

This sounds like a network resource issue (server side anti-virus complications, for example). It might be useful to use the OS to copy the files one at a time, to see if you get an error. For backup purposes, you might be better off using a zipfile (written locally, then copied to the file share) to archive contents (if coding it in Python, you can even skip lock files on export) - V ... View more

Yeah, that was huge missing piece of the puzzle.  If you've already got the database and the experience, then you can enforce data standards as you see fit (as long as you're a velociraptor, you can be as dinosaur-like as you want). - V ... View more

I had a client insist we change our tiny PostgreSQL instance (which they originally required) to a high-end Oracle Exadata database deployment, and asked how may terabytes of storage we'd need. I pointed out that there was just one table, at 56Mb.  The response was, "So, will five terabytes be enough?" When I demonstrated that a file geodatabase was 75% faster then either PG or Oracle for the single simple query we needed, they were willing to knock out the database requirement entirely. Without information on the data volumes involved, and what other utilization exists, it's hard to make a call a DataStore v. EGDB. - V ... View more

Using arcpy.SearchCursor and arcpy.UpdateCursor instead of arcpy.da.SearchCursor and arcpy.da.UpdateCursor is not helping your cause. "Old Cursors" are kludgy and mostly only present for reverse compatibility -- they should not be used for new code (and pre-10.1 code should really be rewritten to not use them). Whenever I've needed to do large database UPDATEs, I've used UPDATE in SQL statements. The usual procedure is to load the change data into a temporary table via FeatureClassToFeatureClass or TableToTable (or even arcpy.da.InsertCursor), then create an arcpy.ArcSDESQLExecute cursor to submit the SQL commands.  My most recent trick was to add an INSERT TRIGGER on the staging table, and let it do the UPDATE on the target table as each INSERT committed. This of course assumes that the target table is not versioned, though this is sometimes possible with the use of versioned views. - V ... View more

If you use objectid serial NOT NULL in the table declaration, ArcGIS will know how to deal with it at registration. - V  ... View more

That query doesn't return a geometry. Query Tables are also a thing, but you can't map them. If you isolated the 't' virtual table as a Query Layer, it might work.  Have you tried? - V ... View more