Latest Contributions by VinceAngelo

A search on that message in the old forums would have produced the same information, but something has gone wrong with the new search software, and they haven't yet been able to build a clean search index (not for lack of trying, I hasten to add). - V ... View more

Have you tried specifying coordinate reference parameters (-x/-G/-P or -R)? I haven't worked much with GEOMETRY on SQL-Server 2008, but the Oracle metadata includes envelope, projection, and resolution data which allows for a better guess on coordref, before then passing the existing geometries through validation. Your invalid entiity type could be due to coordinate snapping to a single vertex (or a two-point line), or the table could just have non-polygon features which don't meet the "nil or polygon" entity flag mask. - V ... View more

populate_uuid_column doesn't repopulate the entire table, just the rows with the all-zeros placeholder, though it's more appropriate for batch operation than for onesies and twosies. - V ... View more

The application not licensed for data creation is ArcGIS Desktop.  ArcView can only read enterprise geodatabases; you need ArcEditor or ArcInfo for write access.  Use the Desktop Administrator to make this change. - V ... View more

What version of Oracle 9i are you using?  The minimum supported release went from 9.2.0.3 to 9.2.0.7 between 9.0sp2 and  9.2sp4. Given Oracle's retirement of 9i and imminent retirement of 10g, you probably want to start heading toward ArcGIS 9.3.1 and Oracle 11g soon. - V ... View more

You don't say which version of ArcSDE you're using, but SE_CLOB_TYPE and SE_NCLOB_TYPE columns would be the moral equivalents  of a MEMO field (STRING and NSTRING are limited to 4000 bytes, so they couldn't hold a full 64k memo).  CLOBs would be half the storage of NCLOBs if you have limited non-ASCII data in them , or they could be 2-3 times larger if you were storing all non-ASCII .  Then again, if you know the memos only contain 400 character strings, you can use the VARCHAR types. Given the Access source, ArcObjects is going to be your easiest tool for extracting the data and transferring to the business table, but you still have some work to engineer a solution to maintain the table after edit.  The ways to accomplish this  are legion, but the best method is dependent on the frequency of update, number of rows (total and changed), and whether you want this to be an automated process. - V ... View more

A pre-10 workflow for this could be to populate nominal UUID values ("{00000000-0000-0000-0000-000000000000}"), then run use "sdetable" to populate with "real" UUIDs. sdetable -o populate_uuid_column -t <table> -c <column> -u <DB_User_name>                         [-D <database>] [-p <DB_User_password>]                         [-i <service>] [-s <server_name>] [-q] My 9.3.1sp1 instance has the default value populated correctly, so you might not need to set any value. Alternatively, you can use the contrib/uuid-ossp module to populate values in the varchar(38) column. - V ... View more

Actually, that table has a history of not being fully modified during upgrade.  If you have an older version of ArcSDE that was upgraded from something even earlier, it's doubtful that the contents are correct. The definitive authority on ArcSDE version is the output of the SE_connection_get_release function, which is what is exposed by the 'sdeping' utility of se_toolkit -- C:\>sdeping -u ***** -p ***** -i sde_eval93 ArcSDE 9.3 Connection Test Utility       Fri Apr 30 14:03:04 2010 ------------------------------------------------------------------------          Server: localhost        Instance: sde_eval93        Database: eval93        Username: *****           RDBMS: PostgreSQL         Version: 9.3.1     Description: PostgreSQL Build 2784(PostgreSQL)      Build Date: Tue Oct 27 10:51:14  2009         Release: 93005 As Eric mentioned, the ArcSDE command-line utilities expose the 'desc' member of the SE_RELEASE structure (which 'sdeping' splits for readability): C:\>sdelayer -o describe -u foo -p ***** -i sde_eval93 -O bar ArcSDE 9.3.1  for PostgreSQL Build 2784 Tue Oct 27 10:51:14  2009 Layer    Administration Utility ----------------------------------------------------- Bar does not own any layers OR user foo does not have access to any of bar's layers. - V ... View more

"sdelayer -o register" is the correct command to notify ArcSDE you wish to use a table with SQL geometry (ST_GEOMETRY or SDO_GEOMETRY) as an ArcSDE layer. "sdelayer -o add" creates a new geometry column in an existing non-spatial table (which may be SDELOB, ST_GEOMETRY, or SDO_GEOMETRY storage, depending on DBTUNE parameters). You *cannot* use "sdelayer -o add" on a table which has had "sdelayer -o register" executed on it.  It sounds like your SDE registry has been corrupted by a failed "register" -- time to contact Tech Support for assistance. - V ... View more

There is usually more than one way to accompish any task.  If you detach, you can toss the files into an archive / burn them to DVD before deletion, for the times when the answer to the question "Are you sure you want to delete?" Is "Yes, oops no - #%@^!" - V ... View more

Please help us to help you by giving a more complete description of the problem -- What database are you using?  Which version, service pack/patches? What version of ArcSDE are you using?  Which service pack and/or patches? What ArcSDE client are you using to pan & zoom? Which version, service pack/patches? What geometry storage type are you using?  What does 'sdelayer -o describe_long' report? How did you populate the data?  What does 'sdetable -o describe' report for the table?  Has this never worked, or did the failures start recently? Have you received any relevant database error messages recently? - V ... View more

The ArcSDE instance metadata tables are owned by "SDE" if 1) You use the SDE user to run the sdesetup utility, and 2) SDE is not registered as the database owner. The data owner will be the user who loaded the data, unless that user is a member of the Administrators role, or has otherwise been granted DBO rights, in which case the owner maps to DBO.  "Best practices" guidelines recommend reserving your SDE schema for ArcSDE instance administration, so you you should not ever load spatial data as the SDE user. - V ... View more

It's sometimes useful to run 'sdetable -o describe' on the target table, since this will show how the columns will get mapped to ArcSDE datatypes.  For example, the "ID" col will be mapped to SE_FLOAT64_TYPE, and is not eligible to be a registered rowid column (even if it were defined NOT NULL). I'll second the recommendation to use "shape", "geometry" or some descriptive name (e.g., "polygon") for the geometry column. - V BTW: Keep in mind that "-e l" will only permit single-part simple_line features -- a safer declaration would be "-e nsl+" (nil or multi-part line or simple_line). ... View more

I believe this was a known issue -- possibly addressed by SP1 -- Spatial views weren't inheriting the secondary coordref (for the initially encoded BASIC precision geometry).  If SP1 doesn't fix this, try updating the SDE.LAYERS table for the view to match the base table. - V ... View more

I wish the 'C' API didn't have the SE_coordref_set_xy_by_envelope function, because it creates more problems than it solves. If you look at the coordref x/y offsets and scale that are generated, you're likely to see that the actual integer value generated on the Y member overflows the 2^31-1 limit. Best practice for ArcSDE coordinate reference creation calls for generating a buffer around your expected data space, to allow for search circles and other objects that exceed the data space.  I haven't had many occasions where I haven't used "SE_coordref_set_xy(coordref,-210,-120,1000000)" when working with PE_GCS_WGS_1984 data. See http://forums.esri.com/Thread.asp?c=2&f=1720&t=287575&mc=4#894148 for information on the storage impacts of using a scale factor in excess of the actual precision. - V ... View more