Latest Contributions by VinceAngelo

ArcSDE has had a column registry for a while now, which captures the column types when the table is registered.  Oracle is the only database which permits this sort of change, so there is no generic business process to support it.  The supported process involves creating a temporary column, populating it, dropping the old column, then adding the old name with the new type, copying from the temp column, and dropping the temp column (or just creating a new table with the new datatype and copying everything, which is far less destructive to table disk organization). IF your table is not versioned, and IF you're willing to take an unsupported (and medium risk) step you can try altering the column registry.  I generally avoid this kind of thing, even though I'm unlikely to be burned by it.  Be sure to change all the relevant properties -- the SDE_TYPE values are published in both the Client SDK and online documentation (SE_FLOAT32_TYPE is 3) -- and be sure to limit your UPDATE statement to a single row. - V ... View more

The three user schemas are all bound to a single instance; you need to move everything. - V ... View more

There were structural changes to ArcSDE geodatabases between 9.4 Beta1 and 10.0 final. It's probably not possible to read 9.4 beta geodatabases with anything but the corresponding ArcGIS beta release. - V ... View more

That's clever, but not all ArcSDE clients grab locks for each query, so you'll want to use the information generated by this approach carefully (certainly not for security auditing). - V ... View more

If ArcSDE works locally, then you shuld be looking for a networking issue, like a misconfigured firewall. - V ... View more

This can't be done. The closest you can come is to run multiple user instances with a single shared SDE repository. - V ... View more

You *must* patch Oracle 10.2.0.1 if you want ArcSDE to function correctly. 10.2.0.1 is known to fail in many ways with ArcSDE and is not supported by ESRI for use with any ESRI product. 10.2.0.3 is the minimum supported release (you should apply the terminal CPU as well). You should always apply the terminal service pack for each ESRI release within a few months of distribution. 9.3sp1 is well over a year old, having been superceeded by 9.3.1, 9.3.1sp1, 9.3.1sp2 and 10.0. Once you apply the required patches, your ArcSDE instance is much more likely to be functional, but you'll still need to make sure that the attribute index statistics are current ("bouncing" the spatial index forces updates on the other indexes as well). - V ... View more

What database are you using?  What release and patch level? What version of ArcSDE are you using?  What service pack and/or patches have you applied? What geometry storage method are you using? Do you rebuild index statistics regularly after your attribute updates? It's likely that spatial index reconstruction is masking your actual problem, and is unrelated to your best solution. - V ... View more

All ArcSDE instances have a limit on the number of concurrent users. If you reach the limit you will get that message. If you have an Enterprise license, you can change CONNECTIONS to a larger value (see the 'sdeconfig' command documentation), though you will eventully start getting Windows errors instead of SE_CONNECTIONS_EXCEEDED if you set it too high. Note: The non-interactive desktop heap OS connection limit is only on Windows server hosts, and applies only to application server connections (not Direct Connect). - V ... View more

The only option I can see is creating a new 9.2.0.8 instance *without* the problematic CPU, upgrading there, then using exp/imp to re-integrate.  Ugly, but it might work. Keep in mind that Oracle 9.2 is no longer supported by Oracle (in fact 10gR2 is now in limbo as well), and ArcSDE 9.3 is the last ESRI release to support 9iR2 (ArcSDE 10 only supports 10gR2 and 11g [32- and 64-bit]).  You may need to consider moving your GIS data to a more modern database, and rigging some backward export mechanism to support the 9i-bound application until you can transition it. - V ... View more

All ArcSDE servers support a full SQL security model (thanks to the databases, which provide this functionality).  Keep in mind that versioned geodatabase tables are limited to {no access, SELECT, SELECT/UPDATE/INSERT/DELETE}, since versioned updates and deletes are really inserts. - V ... View more

A search in the upper bar (of arcgis.com, not just forums) on "multiple ArcSDE services" pulled up at least half a dozen likely links in the first page (of 1100+ matches). If you remember to use the proper product name, the search engine should be reliable. Keep in mind that you're likely to run into the non-interactive desktop heap limitation on Windows hosts if you run more than 66-70 total application server clients across the three instances. - V ... View more

It is generally unwise to separate the ArcSDE application server from the database to which it is tightly coupled, unless you also intend to create a dedicated point-to-point network between the ArcSDE server and the database (crossover cable, backplane to backplane, gigabit speed).  This was especially true way back when 9.0 was released. The only real reason to configure a distributed install is to handle a clustered database configuration, in which case all connections should be Direct Donnect, and the application server component isn't really necessary. I urge you to learn a bit more about ArcSDE, and a lot more about GIS.  Once you start using a modern database,  you'll see that the division between roles of DBA and GIS database administrator has become moot (all modern databases have native spatial datatypes). - V ... View more

Neither Access nor Excel are relational database management systems (RDBMS); since they can keep all data in memory and just rewrite, there isn't any real magic involved. If your source table is spatially fragmented (that is, there is no correspondence between location and row number -- when you draw a single layer at 1/4-1/10 of the total extent and features render in apparently random order), then there could still be a large benefit to draw (and other spatial search) performance with row optimization.  It only becomes obvious on tables with a 300k+ rows or more, but the difference is measureable with as little as 10k rows. - V ... View more

Short answer: No. Essay form: ArcSDE isn't a database, it's an interface to databases. The only way to change table column order with the ArcSDE API is to export in the desired order and create a new table with the result.  If, as in your example, you can coax the database to reorder the columns, then ArcSDE will present them in that order, but a brief web search indicates that SQL-Server, PostgreSQL and Oracle do not permit this as a trivial operation.  Many of the referenced links recommend using a view, which will work, but ArcGIS puts limits on geodatabase participation by views.  If you're going to have to reload the table anyway, consider doing some row-order optimization as well, by exporting in spatial index order. - V ... View more