Latest Contributions by VinceAngelo

PostgreSQL is free software. It has a small footprint and is easy to install (I don't have a copy installed on my toaster oven, but it is running on the microwave). Without an enterprise geodatabase license, you don't have enterprise geodatabase functionality (I'm not going to paste scores of pages of documentation into this thread)..  Query Layers are nice, but they're just tables with geometry columns, which is a pale shadow of what is possible in a versioned geodatabase. - V ... View more

While it's theoretically possible to use SQL Server Express as an enterprise geodatabase (if you're willing to sacrifice performance to a down-throttled RDBMS), you have a Workgroup license, which only works with Express (and has storage, RAM, and user limitations). You can access a PostgreSQL database using Direct Connect without an Enterprise Server license (which is necessary to create or enable  a enterprise geodatabase), but you'll only be able to access Query Layers (PostGIS storage) - V ... View more

No, all networked drives are equally slow (which is why I specified "non-networked 'letter drive'") - V ... View more

The use of network protocols is what causes the significant performance dropoff.  I don't know why, but the difference is significant, and easily reproducible. I used 10k-1m row tables in my benchmarks, and the cost was always proportional with respect to row count (below 10k rows the millisecond timer started to have resolution issues on Windows platforms). If the disk is "local" (seen by the operating system, as a non-networked "letter drive"), you will get better performance than by accessing a networked device, either as a letter drive or via a UNC path.  - V ... View more

All access of data via network shares, either mounted or through a UNC is always slower.  In my benchmarking on two different gigabit networks, it was a consistent 50% performance penalty.  This has nothing to do with drawing (or even OS, since Linux had the same penalty).  My benchmarks were with both ArcPy and the FileGDB API, and no draw operations were a part of the tests.Local filesystem access is always fastest (unless you're using a USB2.0 protocol thumb drive).  I would recommend you evaluate the performance cost before considering it a non-issue. ... View more

This is the expected behavior.  Tables created via SQL are not registered (until you use sdelayer -o register). I avoid the public schema, because data in public can't be registered (only the owner can register, and only in a schema that matches the login). Using the public schema for anything beyond granting general SELECT access also goes against best security practice.  No user tables should ever be created in the sde schema -- 'sde' should be reserved for geodatabase administration tasks alone. - V ... View more

Older Microsoft releases used less than the 31-bits originally used by Esri.  I don't think that's the case now. Esri uses encoded long integers (long long -- 64-bits), but since the mantissa of a IEEE double is 52, the effective width is 54. Accuracy isn't really on the table here.  We're just talking about precision. The whitepaper referenced in my GIS SE answer explains exactly how Esri coordinate references operate. - V ... View more

There's certainly a noise-to-signal issue when the topology is evaluated at a resolution which is coarser than the coordinates are expressed.  Data quality is an issue -- I've seen SQL-Server shift coordinates a dozen Angstroms and be happy with the new geometry, where even the insanely precise default coordinate reference found intersection (all for coordinates which were originally recorded at five decimal places).  The geometries really need to cleaned with respect to the native data precision (be it decimeter, centimeter, or meter).  It's rare that WGS84 data is accurate to under a meter, so thrashing around in sub-millimeter is just a distraction. - V ... View more

I believe they pack the bits themselves, but it's a lot closer to the old BASIC precision limitations of pre-9.2 ArcSDE (and not even the full 31 bits of BASIC in the 2008 R1 implementation).  The part that peeves me is the WKT generated has twelve and fourteen digits, even though only the first four to six are stored. - V ... View more

I think part of the problem is the way you are defining the issue.  ArcGIS has always allowed users to define the precision at which coordinates are captured.  SQL-Server has hard-coded internal limits which have evolved over time, and which are significantly smaller than the precision permitted by Esri. If you wish to reduce the default XY Tolerance of a feature class in an enterprise feature class, all you need to do is specify it during feature class creation.  Of course, this is more often the cause of geometry corruption issues than it is the solution. In the end, what Microsoft considers "close enough" isn't good enough for a data model that can process 54 significant bits. If you want to load geometries outside of ArcGIS, you need to be prepared to repair improper geometries. - V ... View more

The command syntax is exactly the same as the answer provided.  All that changes is the direct connect instance flag and the client library configuration.  Command-line tools are no longer supported, so if you are going to try to use them, you'll need to be creative. A complete description for Oracle includes FIVE digits of release information (11.a.b.c.d) - V ... View more

There are a number of existing threads giving this exact information, which could be located by using this question's title in the search bar (though fewer terms are better -- "register spatial view" would locate my answer to your previous question).  Please remember to include complete version details, for the version of ArcGIS in use, and for the database, in each post. - V ... View more

Unfortunately, you've corrupted the Oracle instance beyond its ability to recover.  The only ways to clear this issue are: Restore from backup, then delete all user-owned tables referencing ST_GEOMETRY or ST_RASTER objects, then drop all of SDE, or Create a new instance and reload. Since your goal was to repopulate, the second option will likely be easier. - V ... View more

You can make the Query Layer SQL expression as complex as you like, but you may be better off prototyping the SQL using Management Studio first, since it can give you more syntax information. - V ... View more

Yes, this is the expected behavior.  There is no such thing as an UPDATE or DELETE in the versioning model, only a pair of INSERTs (one to the adds table, the other to deletes) and a single INSERT to deletes.  If you play close attention to how versioning is implemented, you'll understand why use of triggers is discouraged. - V ... View more