Latest Contributions by VinceAngelo

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

Hmmm... Not sure if that should have been an issue, but it probably isn't because the *table* is served, and only one table is possible with the same owner (if enterprise) or in the same geodatabase (if FGDB). - V ... View more

Note: Cross-posted to GIS StackExchange  ... View more

Does "Long" really mean "LONG"? LONG is not a supported Oracle type. Do a DESCRIBE in SQL*Plus and report that here (you can redact the actual column names, but don't alter the types). - V ... View more

Since it's already a view, you can populate lookups to map the integer domain values to the appropriate values. - V ... View more

Changes made to the base table are not manifested to SDE table metadata immediately. You must first connect as the owner and describe the table (this can only be done as the owner). You do not want to do this if the table is registered as versioned. - V ... View more

Fragmentation is the thing that kills database performance. By mixing "system" data and "user" data, you increase fragmentation.  The auto-increment on the SDE tablespace should be small, while the auto-increment on user data should be large (again, to avoid fragmentation). The same principle should be applied to OS disks (C: for Microsoft, D:,E:,... for  applications; / & usr for Linux, /dataN for applications). You don't have to conform to best practice, but you don't have to have optimal performance, either. - V ... View more

Yes, it's certainly possible, though I suggest you make the effort to learn Python (which is the easiest computer language to learn, ever). Calculate Field field reference syntax is a bit more obtuse, so you want to follow the documentation carefully. That will result in a code block that looks like this: def concatenateFields(f1,f2,f3,f4,f5,f6,f7): l = [] if f1: l.append(f1) if f2: l.append(f2) if f3: l.append(f3) if f4: l.append(f4) if f5: l.append(f5) if f6: l.append(f6) if f7: l.append(f7) return ', '.join(l) and an expression of: concatenateFields(!SITUS_ADR1!,!SITUS_ST!,!SITUS_ST1!,!SITUS_TYPE!,!SITUS_CITY!,!SITUS_ST!,!SITUS_ZIP!) - V ... View more

Which version of Python are you using on the client?  What version of Enterprise are you using.  This could be an error from the authentication server itself, too. - V ... View more

No, that wouldn't be wise, and it might not work -- What if the string field has a width of 5 or less? You'd be better off reviewing the non-NULL empty fields for why they have corrupt values, rather than corrupting the valid NULLs. - V ... View more

I'm not sure what you might mean by this. I've never  modified any settings.  AWS just works. I should point out that there can be  significant performance issues across missions.  I had a three network hop solution (with shared router load among a couple of hundred power users) that was an order of magnitude slower than local access. But that's just AWS being AWS -- tightly coupled applications need to be in the same mission. - V ... View more

Please don't SHOUT in post titles. You actually reduce the number of folks willing to read your post by using ALL CAPS. You can edit the original post so it isn't as hard to read. - V ... View more

Sorry, you won't ever get my buy-in on the idea that geometry types are unnecessary. Storing geometry in multiple scalar columns is a wasted opportunity, and a properly tuned database, even at 500k rows should significantly faster than a "make geometry on the fly" solution, so your test methodology is likely faulty. Randomly distributed features is a known worst case, so you're stacking the deck in the evaluation. You're also testing at the end of a long common pipeline, so the significance of  the difference can be masked. I just did a quick data load of 500k and 2m random global features (by area, so weighted away from poles -- see this StackExchange post for the function), created views, then added an optimized table which was derived from the first by doing an ORDER BY on floor((lon + 180) / 6.0)::int, lat DESC adding an extra integer column of "oldid". On my home PC (6 years old, 3Ghz 6-cores, 24Gb RAM), using a PG11.8 database, I got the following results (all times in pgAdmin) query: SELECT count(geomcol) FROM table WHERE ST_Within(geomcol, ST_GeomFromText('POLYGON (( -120 40, -80 40, -80 70, -120 70, -120 40))',4326)) table rows returned count time (in milliseconds) example1a  500000   8212 119ms v_example1a  500000   8212 250ms example1b  500000   8212 80ms example2a 2000000 32725 126ms v_example2a 2000000 32725 613ms example2b 2000000 32725 100ms   query: SELECT idcol,lat,lon,geomcol FROM table WHERE ST_Within(geomcol, ST_GeomFromText('POLYGON (( 80 40, 120 40, 120 70, 80 70,80 40))',4326)) table rows returned count time (in milliseconds) example1a  500000   8291 119ms v_example1a  500000   8291 323ms example1b  500000   8291 141ms example2a 2000000 33401 348ms v_example2a 2000000 33401 738ms example2b 2000000 33401 315ms   When I changed the search geometry and reversed the query order (v_example2a, example2a, example2b), the view took an additional 100ms over the table, so the example1a query was helping to cache the pages for the view (I should have made 3 tables). I used to have low-level query performance tools, but the ArcSDE API was deprecated, and those tools haven't been ported to Python yet (too busy).  Still we can see that the geometry is clearly better than "on-the-fly" generation, and that the slightest bit of defragmentation (6 degree bands) often improved performance (though not in human perception with so few rows involved). - V ... View more