Latest Contributions by VinceAngelo

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

Please ask your questions using text.  Video is extremely ineffective as a way to ask a question (no one will watch it), and the lack of any text means that no one with the same problem will ever find it. -V ... View more

But they're different instances, with different database releases (?? - this wan't clear), right?  Therefore 10.3/10.4 is not the only variable. What tweaks were you making to change view performance? In the end, you'll need to determine the optimizer query plan, and figure out why the query is processed so inefficiently. - V ... View more

First off, there's no such thing as an "ArcSDE Query Layer" -- Query Layers are based on the assumption that you do not have an enterprise geodatabase (ArcSDE no longer exists), and use the native spatial type capability of the database to perform queries.  The exception here is that Query Layers understand how to interact with the SDE.ST_GEOMETRY datatype (on PostgreSQL, Oracle, DB2, and Informix, where that type exists).. Therefore, your query on SQL Server will only work if you are using one of the Microsoft spatial types (Geometry or Geography) for geometry storage, and will only work with the spatial functions defined to support those types.  The Microsoft documentation is a good place to start looking for the within operator​ and proper syntax for using it.  Be sure to organize your query so the polygons are used to find points, since that will require fewer comparisons than looking for points contained by polygons. - V ... View more

Cross-database queries usually perform poorly.  If you have spatial data somewhere, you'd be much better off accessing that data locally, or by establishing a process to replicate it (little 'r' "replicate", vice big 'R' "ArcGIS Geodatabase Replication") to the database to which you do have access. - V ... View more

Generating geometry on the fly is very expensive, both in raw performance cost and because it's not possible to build a spatial index, which effectively reduces the number of features supported by this sort of query below ten thousand rows (where a real geometry layer could easily support tens of millions of rows). While it's possible for a database to do this sort of query on a regular basis, you really ought to evaluate using the query to populate a "materialized view" (a real table, which contains the data after all the crunching is done), which will give you optimal performance. - V ... View more

The work-around is to populate vertices in the shape buffer which approximate the curve, instead of relying on ArcGIS to use CAD curves to hide the blocky shapes which are being populated in the shape buffer (which are used to calculate area via Simpson's Rule, as stated back in January). - V ... View more

Please include your code in the post, as not everyone would be willing to download a zipfile from some other location (as part of computer security policy, I won't even download zipfiles from GeoNet) - V ... View more

Instead of adding to a 3-year old post, it would be better if you created a new post, referencing the other one as necessary. It's been a long time since I responded to an application server install question, but the root cause is probably the same -- failure to use LOCAL (or TWO_TASK on Linux) as a variable instead of ORACLE_SID in the dbinit.sde file (as documented in the install instructions). I have to recommend that you abandon Oracle 10gR2 and adopt 11gR2 as the minimum database release.  ArcGIS 10.4 and beyond doesn't/won't support Oracle 10g or 11gR1 or even 11gR2 below 11.2.0.4. - V ... View more

You need to debug your code, since it does not produce the correct output.  We'd be willing to help, but you need to do the majority of the work.  The other option would be to pay someone to review your code. I've written a number of shapefile readers and writers in both Java and 'C', and the core code was under 100 lines.  Once you've verified that the header isn't mangled, the code you'd need to post would be under 40 lines.  If the problem is with dBase, then it might be as large as 60 lines (most of it in a large case statement by datatype). Expecting folks to download and review your code without context may be the reason you didn't get help from the QGIS list.  I know a question like this would be closed immediately in GIS StackExchange for failure to include code (an MCVE) in the post. What we'd need to help you is for you to verify the dBase (.dbf) component, then review the 100 byte header contents, then review the individual shape contents.  If you write exactly one shape then post the contents of bytes 101 through EOF as a hex dump (`od -t x1` is a wonderful tool), along with the code that generated that .shp record, we'd be able to tell you what was wrong. - V ... View more

You might get more responses if you provide a relevant code sample in the body of the question, along with a description of the error you are receiving. - V ... View more

Since you haven't included code, or mentioned what language you were using, or even the version of ArcGIS, I doubt there's much we can do to help.  I can say that this error is consistent with a failure to include a necessary jarfile in your SOE zipfile when using ArcObjects Java.  If this doesn't pertain to your situation, you'll need to go about things the old-fashioned way, stripping the app down to dummy code, then adding pieces back in until it breaks. - V ... View more

There are many potential routes from "days since 01-Jan-1900" to a proper timestamp. One of the easiest might be to subtract 25569 (the Excel value of 01-Jan-1970), multiply that day value by 86400 (60*60*24 seconds per day), then use "seconds since 01-Jan-1970" to make a conventional date type. - V ... View more

The ability to do this depends on the geometry storage and the RDBMS in use and what you're planning to do with the results (neither of which are mentioned in your question, nor is the ArcGIS software version). Creating a new table with SQL is actually very simple, BUT it's also a potential way to corrupt your geodatabase.  The issues include: Will the table be accessed through a Query Layer, or does the resulting table need to be registered with ArcSDE and/or the geodatabase Does the SQL query result in multiple geometry classes in the same table (e.g. polygons and lines)? Will the table change schema in subsequent construction runs? (Truncate vs Drop/Create) How are you planning on preserving the registered rowid (ObjectID) column? - V ... View more