Latest Contributions by VinceAngelo

Unfortunately, you have corrupted your geodatabase data dictionary.  Even if you used the safest command-line option available ('sdetable -o delete') you would still have corrupted metadata (no binary in $SDEHOME/bin is geodatabase aware). You may be able to use ArcCatalog to delete the remaining feature class fragments, though you might need to recreate the raster column before a GUI delete would be fully successful (Tech Support would be a great resource at this point). The exact steps for SQL maintenance to clear the corruption depend on the version of ArcSDE in use, and, if necessary, are better executed under the close supervision of Tech Support. - V ... View more

None of the above.  A raster dataset is a geodatabase entity -- it must be deleted via ArcGIS tools.  The only command-line deletion option is through Python. - V ... View more

The example above looks like a search and replace went hog-wild. It also doesn't take the fact that you want to register a view into account (views require USER-set rowids). Try: sdelayer -o register -l ARCVW_BUILDING,shape -e nac+ -C OBJECTID,USER -P HIGH -t ST_GEOMETRY -i 5151 -u ERGIS -p ERGISpass Then again, if this view was created with 'sdetable -o create_view', and it didn't capture the geometry column correctly, then you really need to start over with view creation. I generally recommend that views involving SDE.ST_GEOMETRY (or MDSYS.SDO_GEOMETRY) columns be constructed via SQL, and the result registered, rather than using 'sdetable -o create_view'. If you give more details in ASCII (vice a Word document), you're more likely to get responses. Keep in mind that Oracle 9i (and 10g) are no longer supported by Oracle, so it's going to be more and more difficult for Esri to support ArcSDE on these older databases. - V ... View more

The best way to create a view which includes an ST_GEOMETRY column is to use SQL to define the view, making sure that it returns a NOT NULL integer (SE_INT32_TYPE) column, then to use 'sdelayer -o register' on the view, with the INT32 as a USER-set registered rowid column. - V ... View more

The product that was initially named 9.4 was released as 10.0.  I guess they missed the manifest during renumbering. - V ... View more

Access to 10 servers from 9.3.x clients is not formally supported, though it has seemed to work (at least from the 'C' API). ArcSDE 10 SDKs are supported for use with all previous releases which are not retired (9.1 and earlier are retired). - V ... View more

There are too many missing columns for the image to be of use (it seems as if both XY and Z parameters have changed, but I'd need all seven FALSE* and *UNITS values in each row to be sure). You don't need console access, just a client with the 'sdestats' executable (with the rest of an SDEHOME available for DLL resolution). Once a release reaches "mature" status (as 9.2 has), no further patches or hotfixes will be generated. - V ... View more

I think the issue here is the use of Direct Connect to both instances.  You might have more success if you use an SDK SDEHOME, since they have most of the server libraries installed in one directory. I mostly use my own custom raster utilities (sde2raster & raster2sde from se_toolkit) to copy rasters, and I rarely use Direct Connect for data loading (I usually load on the server anyway). So you have several options: 1) Use application server connection for one or more of the connections. 2) Use an SDEHOME that has both Oracle and SQL-Server direct connect libraries 3) Use a different utility that only makes one connection at a time (the data flows through a pipe, so you can change SDEHOME variables before invoking the second instance) Caveats: A) No enterprise ArcSDE utility (or custom application built with the 'C' API) is supported for use with Express-based Personal ArcSDE or Workgroup ArcSDE. B) 'sde2raster' has a known issue with sparse rasters, where NODATA values aren't populated correctly when entire tiles are missing (though this seems to have disappeared at 9.3) C) 'sde2raster' uses only lossless compression on the data stream to 'raster2sde', so images with lossy compression will expand in size significantly during transfer D) Copying the SQL-Server server DLLs to an Oracle SDEHOME (or vice versa) may work but is unsupported (because it would not be upgraded with a service pack). - V ... View more

Unfortunately, when you set out to use the FileGDB API to create new tables, you are choosing to take over ArcGIS' role in feature class creation.  Using generic parameters for table creation may be possible, but it's unlikely to generate high quality datasets -- if you don't know, at a minimum, the spatial units being used and the range of possible values (and alter the spatial reference to correspond to them) then I'd argue that it's not really worth the effort of loading the data. I know the samples execute cleanly on the reference machines, so this should probably be your first line of inquiry with Tech Support. - V ... View more

0.066 degrees is an awfully small grid size.  How large are the objects?  Do they vary greatly in extent? It probably wouldn't hurt to set the grid size to 5 or even 30 degrees, load the features, and *then* try to determine a more appropriate grid size. - V ... View more

Most raster load failures have to do with I/O runtime of the session. SQL-Server 2000 was famous (or, rather, infamous) for not sustaining long connections. Are you running the required SP4 build for ArcSDE 9.3.1 support? Using lossless (LZ77) compression is always faster in both load and query than NONE compression. You may need to clip that image into 32k X 32k chunks, then mosaic it back in to prevent the database from failing (use the UL tile first, working the load across from left to right before dropping south; be sure to disable pyramid construction until after the load is complete). - V ... View more

There are many possible solutions; determining the best solution requires more information... What version of Oracle are you using [A.B.C.D notation] Which CPU has been applied? What version of ArcSDE are you using? [version and service pack, plus any patches] How are the layer's index parameters currently defined? ('sdelayer -o describe_long' output will suffice) What is the origin of the data which is being loaded?  What tool is being used to load it? How many rows exist in the layer before import?  How many rows are being added? - V ... View more

Which version or SQL Server are you using?  Which service pack? How large is the raster (H x W x P & disk storage)? What compression algorithm and options are you using for import? - V ... View more

Without knowing the SRID constants and layer envelope, I can't tell you how to detect incorrectly decoded shapes. Also of use would be the output of 'sdelayer -o stats', to report the sizes involved. You should also start an incident with Tech Support, since the problem may exist in versions which are still under active maintenance. - V ... View more

Every layer has an entry in the SDE.LAYERS table. Every LAYERS row has a mandatory SRID and an optional SECONDARY_SRID. These are are foreign keys into the SDE.SPATIAL_REFERENCES table, where the FALSEX, FALSEY, and XYUNITS columns store the offsets and scale. What are the values stored in your instance for the layer you are accessing? The bytestream of the shape is extracted into an integer array which is easily accessible to the SeShape object. setCoordref changes how that array is interpreted without changing the array (at least that's how it worked when I last used it). changeCoordref modifies the array. In a worst case, you can do the math yourself: newX = (floor((oldX - primFalseX) / primXYUnits + 0.5) * secXYUnits) + secFalseX; newY = (floor((oldY - primFalseY) / primXYUnits + 0.5) * secXYUnits) + secFalseY; - V ... View more