Latest Contributions by VinceAngelo

So replicating 3 tables from MySQL into PostgreSQL to display via ArcMap will never work. No, that's not correct. Since the 10.4.0 release, PostgreSQL is special in that you can access PostGIS tables read/write without an enterprise geodatabase license. I do this all the time at client sites. Sure, you don't get full geodatabase functionality, but you can create feature classes in a PostgreSQL database via Desktop (Standard or higher) or Python (ArcPy), and you can insert to tables created via SQL with ArcPy cursors. The key is having a simple database design and utilizing the serial datatype to allocate rowid columns, to preserve 32-bit integer identifiers in the tables for Query Layer access. - V ... View more

It's really difficult to predict the difference in storage between RDBMS implementations. That said, I haven't noticed huge differences (except with respect to the RDBMS binary catalog overhead -- Oracle is a *huge* install). Note that porting an SDO_GEOMETRY-storage geodatabase to Geometry-storage would produce different characteristics than an SDE.ST_GEOMETRY source (due to compression in the SDE.ST_GEOMETRY implementation). - V ... View more

Mike - I'm afraid you may be courting sorrow and woe. Let's say you've ordered a minivan to tow a small "teardrop" camper, then at the last minute, your spouse mentions that an 8-ton "fifth wheel" camper was ordered instead. Even if you can locate and install a fifth-wheel tow-hitch trailer, and paint a picture of a monster truck on the window of the camper, it's unlikely you're going to be able to visit Rocky Mountain National Park. Right now you're still trying to get the wiring on the fifth-wheel cart correct, but I worry that you may not get this contraption street-legal. If you do get the wiring in place, and if you're only headed to a state park 5 miles away, maybe this will work for a while, but I don't think you'd be able to get warranty service on the minivan engine or transmission (or a refund on the camper). You may need to start an "expectation management" campaign, because the performance characteristics and reliability of your solution may not meet requirements.  Even if you store the geometry in PostgreSQL and link to the foreign attributes through views, you're likely to have a temperamental and sluggish application. - V ... View more

I've done more than my fair share of programming in the TCP/IP stack, and there really isn't any reason for transient disconnections on a reliable network.  Since TCP/IP hides the physical layer from the application, frequent TCP connection failures are the very definition of an unreliable network.   The very nature of Direct Connect connections is to utilize the network protocol of the database API. If they report a connection failure, it's not possible to reject the error and force it to remain connected. At this point, all the cached commands in the Direct Connect thread queue are invalidated. It's not just that this is a non-simple task, it's a nigh-on impossible task. If you then multiply by a dozen different Direct Connect drivers, the magnitude of the problem is exposed.   In fact, database transactions are what make it impossible.  You can't rejoin a transaction after it fails, and that low-level failure during a COMMIT is what invalidates the uncommitted changes.  Remember that the versioned geodatabase model saves the individual undo-able edits as states in the versioned state tree, and the act of "saving" is really only changing the state of the version associated with the edit session to the last created state. So, in a sense, you can access the committed states through the point where the editing failed, but you'd need to take heroic (and unsupported) measures to align the version to that state.  If the edit session is not versioned, then a simple implicit ROLLBACK erases any memory of the edits.   Best practice remains to save frequently during an edit session.   - V ... View more

Please understand that you are saying the equivalent of, "It's a disgrace that a painter can't immediately continue his brush stroke when the ladder he was using is dragged down the street in a brief safety line mishap. It's completely insane that the brush box doesn't articulate this hazard." For a TCP/IP application, losing network access, even briefly, severs the communication link.  Even if the database client software has the ability to re-establish communication, it's unlikely that this reconnection protocol will be entirely seamless with respect to the client application, and the hash that this makes within the transaction model isn't likely to make application recovery any easier. It takes a great deal of effort to find the right balance of database API options to implement geodatabases with reliable network access. It's unlikely that the same order of magnitude of performance would be achievable if the client library were optimized for unreliable connectivity (assuming this is even possible). It doesn't seem fair to blame a third party for the error messages generated in some other vendor's library by failure five or six levels away in the OSI model. If you need to work with unreliable network access, you need to use tools which do not require continuous connectivity.  There are a number of available options using the Esri technology stack, including disconnected editing and feature stream editing with REST endpoints.  - V ... View more

No, the underlying ArcSDE API constant, set to 32 (but not counting the string terminator) has not changed since SDE 3.0. ... View more

If you prepend the column name with "DISTINCT ", the field contents becomes 31 characters long, which happens to be the maximum column name length.  Very curious. - V ... View more

The PATH (system environment variable) needs to change with release, since the version number is part of the name with the site package. sys.path is assembled from PATH and site package loading instructions. I prepend C:\Python27\ArcGIS10.n; or C:\Python27\ArcGISx6410.n; to PATH in the cmd.exe window or shell script (where n is the installed release)  - V ... View more

If you have both Desktop and Server on your machine, you must have two copies of Python (32-bit and 64-bit).  If you had an old version of Python with the 10.3.1 install, then you might have as many as three installs (four, if Server or 64-bit Background Geoprocessing was installed). import arcpy works on every one of my 10.5.1 installs (both 32-bit and 64-bit, since I install Desktop 64-bit Background Geoprocessing), so the problem is specific to your installation. You should make sure the appropriate bin or bin64 folder is in your PATH variable (different install order with default PATH will cause all manner of install issues -- If Windows finds the right DLL name, but it's the incorrect word size, it will report "File Not Found"). ... View more

You left off the registered rowid column. You should ALWAYS have a NUMBER(38) column. Simple table creation likely defaults the SRID to zero, which doesn't have Z and M settings. I haven't used Oracle in a while so you 'll need to explore how to specify an appropriate spatial reference ID. - V ... View more

The spatial reference properties of a layer are established at creation. You can't add Z or M (or both) to an existing layer. What was the exact SQL you used to create the table? - V ... View more

Note: Previously posted in  GIS StackExchange, but put on hold for being unclear. - V ... View more

This is probably one of only two valid reasons to use an account with Administrator access through a Database Connection folder (the other being for geodatabase upgrade).  It's also a reminder to make sure that core tables are owned by a "headless" data ownership user, so that it is safe to archive (in FGDB)  and delete the tables owned by departing users. - V ... View more