Latest Contributions by VinceAngelo

Which version of ArcSDE did you license?  "Personal ArcSDE" and "Workgroup ArcSDE" have concurrent user limits, while Enterprise ArcSDE does not (well, it does, but it's database resource configuration which is the determining factor -- once you're into hundreds of users, it doesn't really seem like a limit). - V ... View more

You need to upgrade your client to at least 10.2.0.3 (the minimum), or all to the same release as the server 10.2.0.4.  ArcSDE will not function correctly with Oracle 10.2.0.1, which is known to give spurious permission errors and to fail frequently. - V ... View more

You cannot control the allocation of SDE-set registered rowid column values in geodatabases and "in-memory workspaces" aren't, as James pointed out, full geodatabase implementations.  The task of keeping track of pieces of a database, editing them, and merging the result back into the original table is quite challenging, which is why the Disconnected Editing solution was developed.  But you can't pick and choose pieces of that solution (the restrictions it imposes were necessary to make the solution work).   If Disconnected Editing doesn't meet your requirements, you'll have to decide if the days, weeks, or even months of effort to make your own in-memory solution are worth your time, but your design will have to actively track previous objectid values in an additional column, and be prepared to update, delete, and insert appropriately when the transition back to persistent geodatabase occurs. Good luck. - V ... View more

I'd have to see (and reproduce) research that showed that using multiple filegroups (I leave the primary to the database, place sde in one, raster in two, and vector in at least two) hurt performance before I stopped using them.  Using one big file puts you at the mercy of fragmentation, and doesn't allow you to split data across multiple independent disks.  You can always defragment the files on disk if you've got them. Just my $0.0204 (with inflation). - V ... View more

GRANT OPTION is a SQL standard thing, required by Oracle. It is necessary when a non-owner attempts to grant other users access to a table with a view. See the Oracle docs for more info. - V ... View more

You can't control the objectids in either location, and can only keep track of old IDs and edits through a great deal of effort.  It's generally easier to use ArcGIS as it has been designed, so I think you should look into the Disconnected Editing model. A search on "Disconnected Editing" should pull up a wealth of information. - V ... View more

It looks like the search engine issues are closer to being resolved, since a search from http://support.esri.com on "st_geometry trigger" turned up this in the first page.  You'll also need to maintain the objectid appropriately (I recommend a USER-set registered column, but then it can't participate in advanced geodatabase functionality). - V ... View more

The only way the objectids could be consistent is if you a) selected all features, b) inserted them in objectid order, and c) the source dataset started at 1 and did not have any gaps.  If you want to preserve the old ids, you'll need to insert them as an additional column (e.g., "prev_oid integer not null"), since there are no guarantees about SDE-set objectid allocation (except that they will be unique non-zero positive values). - V ... View more

It would be quite wasteful to update the layer extent every time a geometry is inserted.  The layer load utilities generally maintain an envelope of the  newly added features and update once at the end of loading (and only if it would change the extent). I usually set my envelope to the full extent at layer creation, so it doesn't get updated (which also has the side effect of always having the same display extent in ArcCatalog for all layers).  The 'sdelayer -o alter' command allows you to set an extent ('-E minx,miny,maxx,maxy') or calculate one ('-E CALC').  I recommend the former. - V ... View more

The tables only need entries in the geodatabase metadata tables to prevent recreation.  The easiest workaround is to create an empty table with the same name via SQL, then use Catalog to delete it over again.  If that doesn't do the trick, contact Tech Support, and let them walk you through the other procedures. - V ... View more

Timing on 'se_toolkit' enhancements is driven by my project schedule.  I haven't needed many raster updates of late, and I've been saturated by billable work, so there hasn't been much progress on GeoTIFF support.  I need to fix the scanliner bug as first priority, but GeoTIFF export is a close second. You really ought to make sure your 'sderaster' issue is at least in the Tech Support tracking queue. - V ... View more

If you use SQL to DROP registered tables, your geodatabase registry could be corrupted, which can produce cross-association when new layers are registered.  At this point, you really ought to contact Tech Support, since they have the tools to diagnose and fix registry issues. - V ... View more

A spatial view requires an existing geometry column; you can't build one on the fly as a part of view creation. This task should be fairly easy to accomplish if you're using a modern ArcSDE (one with ST_GEOMETRY), but if you're not a programmer you're going to need a SQL person to assist you, since writing the trigger to autopopulate the geometry column can be tricky. - V ... View more

What version of Oracle are you using (A.B.C.D notation)? What version of ArcSDE are you using (including service pack)? What version of ArcGIS are you using (w/ SP)? Please provide the 'sdetable -o describe', 'sdetable -o describe_reg', and 'sdelayer -o describe_long' output for table1, plus the USER_SDO_GEOM_METADATA content for that table. Objectids should always be positive non-zero values, so your where clause shouldn't do anything. What does "SELECT COUNT(*) FROM table1 WHERE objectid <= 0" return? How about "SELECT COUNT(*) FROM table1" and "SELECT COUNT(DISTINCT objectid) FROM table1"? If anything, it's not the layer which has been corrupted, but the instance. Have you used DROP TABLE on any table registered with ArcSDE, or any layer registered with the geodatabase? Has the 'table2' table ever existed in instance1? - V ... View more

Databases should always be run on physical servers.  ArcSDE should be run on the same physical server as the database (unless you're using clustered database technology). The only reason to run ArcSDE on a virtual server is if you'll only be using Direct Connect. - V ... View more