Latest Contributions by VinceAngelo

Sorry to make your life more difficult, but you actually have two choices -- null geometries and nil geometries (the difference is that one is a true NULL, and the other is a shape with zero vertices).  Plus, of course the unchanged geometry at that time, which would be easier to render.  Whatever you decide, the ArcSDE model would support. - V ... View more

[my longer, more complete reply got eaten by a post failure] It is not necessary to change the index size to index new features. If a spatial index exists, then newly inserted features are reflected in the index, and are immediately available. I question the wisdom of a requirement to rebuild the index with every load.  Any table that is small enough so that this is is not a very expensive task is unlikely to see measurable benefit. I also question the assumption that the grid selected by "AUTOMATIC" calculation is in fact the best possible grid size.  Optimal grid calculation must incorporate knowledge of the queries to be performed, something which "bouncing" the spatial index (load-only true, index size 0, load- only false) cannot provide. Its unlikely that even a poor grid size selection will result in a measurable performance hit with a feature count under 50k.  By the time you reach a million rows, the grid size *can* have measurable impact, but I wouldn't trust the AUTOMATIC-calculated index size with that many features without further experimentation. In my experience, spatial reference parameter selection and spatial defragmentation have had more than an order of magnitude greater impact than changing the grid size, so you probably don't want to spend too much time on grid size optimization . - V ... View more

It's probably not wise to assume that the auto-generated index from one record is the optimal grid size.  It would probably take a few hundred records before the calculation algorithm has a large enough sample size to take a reasonable guess, and it's still just that, a guess.  In reality, it generally takes ten to fifteen *thousand* records before the grid size makes any measureable difference in performance.  Generally speaking, you don't want any index at all until the table has all records, since the performance cost of loading features with the spatial index enabled is relatively large (this is the reason to use Table::LoadOnlyMode). You certainly wouldn't want the API changing the index size as you add features , since that would mean an O(N^2) or O(N^3) performance cost, and you might never complete a million row table load. - V ... View more

There is no way for ArcSDE to restrict a spatial query.  Some *applications* (like ArcGIS Server) can limit the window from which you are permitted to query, but that's not done at the SQL level. - V ... View more

I'm pretty sure File Geodatabase doesn't support views (there isn't an SQL engine behind it).  If you copy a view into a file geodatabase, you'll get a table with the contents of the view at the time of the copy.  It would be quite a stretch to call this a materialized view. - V ... View more

Only ArcGIS supports the XML data generated by ArcGIS.  You can use Python tools as a command-line loading option. - V ... View more

Before ArcSDE 9.2, ArcGIS didn't use HIGH precision coordinate references, which meant that it wasn't possible to create a coordref that could store all possible values in that coordinate system at reasonable precision.  In truth, you can change the coordref from the ArcGIS post-9.2 default, but it is sufficiently difficult that most folks don't bother. - V ... View more

I should clarify -- If you can't change the objectid sequence, then you can't change feature order, and that would mean you can't optimize your data. Instead, the copy uses the SDE-set IDs, which allocate sequentially, without regard for previous order, leaving the opportunity for optimization. It is often the case that copied rows *do* have the same rowid column value when being copied, but because the tables are constructed using SDE-set IDs, it is not possible to guarantee it (and it wouldn't be possible anyway if the previous table had been edited so that the SDE-set IDs were no longer sequential). The only way to preserve objectid values would be to use database and ArcSDE tools to change the table to USER-set rowid, export the data, import it as USER-set, then alter the source and target table registration to be SDE-set. The thing is, if you're going to do the work to make *this* happen, then you should put forth the extra effort to do the query in spatial index order, which would optimize created feature order, which should result in improved performance with every query. And if you're going to do that, then you should also optimize your coordinate refererence to reduce storage and improve query performance. And if you've made all theses changes, what difference would it make if the objectids were assigned in creation order, since you really shouldn't be using SDE-set rowid values for external application purposes anyway. - V ... View more

There is no method using ArcGIS tools to populate SDE-set rowid columns with previously existing values.  In a number of respects this is the last thing you want anyway, since it also means there is no hope for doing spatial defragmentation on database copy. - V ... View more

The RDBMS vendors generally do a better job of telling folks how to administer their software, but the ArcSDE documentation does detail the necessary permissions (the page that you cited does not pertain to this, however). ArcGIS 10.1 has a capability to create users, but after 23 years as a professional DBA, I wouldn't ever need to use it. - V ... View more

I would recommend you work with Tech Support on this issue. - V ... View more

You should not ever use the SDE user to own or manage spatial tables.  Best practice is to reserve SDE for ST_GEOMETRY and SDE schema mangement, using one or more "data ownership" accounts to own and access spatial data.  While the SDE user needs extraordinary privileges at install and upgrade, it barely needs more than CONNECT at most times; granting SELECT ANY TABLE to the SDE user is generally unwise, and not recommended. - V ... View more

You've probably got more than one issue here.  First off, I don't think you can just switch Microsoft applications and have Personal or Workgroup geodatabases function correctly (only Enterprise ArcSDE functions in SQL-Server Standard/Enterprise).  Second, ArcSDE functionality is hard-coded into the triggers of SQL-Server, and it is not supported when you change database names.  Third, those "problems" may have caused or been caused by corruption of the database instance data files; it probably isn't helping to move the instance information about like this. - V ... View more

I already included one reason -- some storage types are implemented as multiple tables. The closer you come to simple feature classes (aka ArcSDE layer, aka database table), the more flexibility you have in using SQL for nominal management.  Don't get me wrong -- You *can* always use SQL (I do, albeit rarely), but if you do it wrong, you'll be validating your backup integrity more than most sites. - V ... View more

There's always the option of doing a trace to see what is going on, but if the doc says it does a TRUNCATE, and the best possible solution is a TRUNCATE, then it's pretty likely that the command is doing a TRUNCATE (and it's likely to apply it to any parallel tables manifested by different storage types, too). Using SQL on objects registered with the geodatabase should be a rare event; running a SQL TRUNCATE on a versioned table would be a very bad thing indeed. - V ... View more