Latest Contributions by RobertHu

It is roughly like these, 1. Create a GDB feature class (FC) and make sure the field schema matchs the spatial view (SV). 2. Build indexes on the FC as necessary. 3. Run sdeexport and directly pipe into sdeimport to populate the FC. In the attribute file, I will not include OBJECTID field,     sdeexport -o create -l <SV>,shape -a file=<att_file> -f - .... | sdeimport -o append -f - -l .... 4. Rebuild index (sdetable -o rebuild_index) and statistics (sdetable -o update_dbms_stats). In the subsequent update, it is roughly as these, 1. Put FC in load only mode (sdelayer -o load_only_io) 2. Truncate it (sdetable -o truncate) 3. Step 3 above 4. Put FC back to normal mode (sdelayer -o normal_io) 5. Step 4 above. I am doing these using C-shell script in Unix and batch file in windows. I think if you leave your views in the DB (I dynamically create the views before update and drop them after update in my script), you can easily accomplish all these using python/GP tools, except the rebuild_index. Thanks! ... View more

Code Value Domain? ... View more

I have a 1:M spatial view, too. The M is on the shape side. My solution is to create a feature class by "materializing" the spatial view, and use the view to update the FC periodically, say once a day at night or once a week in weekend. My users can only access the FC, so they do not have the ArcMap/ArcCatalog inconsistance. Another benefit is that the performance of the FC is much better than the view. Because on my table side, it is a table view joining several tables in a complicated way. The spatial view actually is a view of a FC and a table view. Very slow. Thanks! Sorry. The M is on the table view side. ... View more

Hi Melissa, Are there lots of changes on the feature class and the joined tables in your main work hours (say, 8:00am - 5:30pm) every day? If so, does your business flow require those spatial view users to see live changes? If you've figured out a solution for your issue, forget my questions. Thanks! Robert ... View more

Hi Ivan, The "real" info of raster dataset or catalog stores in <schema>.SDE_blk_# table. Check the sde_raster_columns table to find out what # is associated to the raster dataset your are interested in, then you know which BLK table contains the raster info (pixles). See the link for the raster dataset structure, http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Raster_dataset_and_raster_catalog_storage/002q0000007p000000/ I mornally just use the SSMS's report functions to get the size of a table. Thanks! ... View more

Hi Mike, Are you using ArcSDE 10? In 10, you are supposed to be able to kill direct connections easily. Say, if you use SQL Server, you can do it like this, sdemon -o kill -t all -i <direct connection info> .... If you use sde schema, you must grant sde user more privilege - processadmin server role. All these are in the new ArcSDE Administration Command Reference. Thanks! ... View more

When we were in 9.3.1, we tried to modify the srid at table/FC level using SQL directly. It made the SQL spatial function, i.e. STIntersects, worked. But the FC's behavior in ArcCatalog became wired. That's a bigger issue we don't want to deal with. So we gave up that approach. There were discussions about srid/auth_srid management in this forum. (Can't find the link anymore). One approach is roughly as create a feature dataset with the exact spatial reference you want at the begin. Then, while creating new FCs, ALWAYS define the spatial reference by referencing to the predefined FD. This is the method we use now. Thanks! ... View more

What versions of ArcSDE and ArcGIS are you using? We had trouble to manage the srid for our FCs when we were in SDE 9.3.1. After upgrading to ArcSDE 10 and ArcGIS 10, it seems the only auth_srid matters. I think it is the spatial reference factorycode. If you use SQL geometry, it doesn't matter what the srid is, as long as your FCs use same auth_srid, the SQL spatial functions/motheds will not fail. Whether it will give you the result you expect may still depend on other parameters (I am not 100 percent sure), such as falsex, falsey, etc. Thanks! ... View more

You are right if you are using ArcCatalog 9.3.1 or early version. But before doing it, ensure no one is on the the feature class. If you use 10, you have to explicitly select "REVOKE". Thanks! ... View more

An ESRI tech support analyst reproduced the behavior I had encountered on their site. He figured out a solution. It is that before grant sde user db_owner database role, STOP THE SDE SERVICE FIRST. Good to know this. Thanks! ... View more

Hi Keith, I did a few tests, my processes are different from yours, just want to share my experience. Here are my steps, 1) Select one polygon using attribute from feature class 1; 2) Select polygons from feature class 2 that intersect with the polygon from the above step. The FC2 contains about 800,000 polygons, and the polygons being intersected are about 8000. The first test was done in ArcMap. The response times for the second selection are, SQL Geometry: 23.66 sec SDEBinary: 19.19 sec The second test was in SSMS. The 2 selection steps were merged into one SQL statement. The response time is 4 minutes 36 seconds. Both ArcMap and SSMS were launched on same client computer. The SQL geometry FCs and SDEBinary FCs are in different DBs, but under same SQL Server instance. The configurations of the two DBs are not same, for example, the sizes of data files are different. (Ahu..., Apples to Oranges). I don't think my tests are conclusive in terms of performance. If I have to decide between SQL Spatial and SDEBinary, instead of performance, I would ask myself a different question. Just my opinion. Thanks! ... View more

I reset my instance to 8192K, and couldn't see difference. it could be because I don't have a well controled testing environment. Robert ... View more

Hi Nicholas, I don't have a sure solution for you. But based on what we did in Oracle, I think you can do it in SQL Server this way, 1. Export user name and password_hash information from sys.sql_logins system view to a text file. 2. Run CREATE LOGIN <loginName> WITH PASSWORD = <hashed_password> HASHED <other options>, where the loginName is a user name from the text file, the hashed_password is the associated hashed code. Hopefully this is what you are looking for. Thanks! ... View more

Q1) Can I prevent credentials from being copied into the MXD, yet still use connection files? e.g. I don't want any prompts for u/n and p/w Q2) How secure is the encrypted password in an MXD? Although this may be a moot point if merely passing around an MXD gets one access to all SDE data sources in it--sensitive info might easily be accessed this way without proper authorization. Q3) Why was the connection file behavior implemented this way? Evidently, most software products using connection files do not copy credentials into product files--they merely store a reference to the connection file. A1) While creating your SDE database connection, uncheck the "Save username and password" box. The mxd create using that connection should not have your username/password embedded. It is a little bit annoying when another person opens it at first time. A2) I don't know exactly how secure a password is in a mxd. But in a ESRI training class, I did ask same question. The answer from the instructor was something like as for as he knows, nobody ever complained or reported to ESRI that the password not secure enough in mxd. A3) I think the purpose is to make map sharing very easy. Believe me, lots, lots of people like it this way, even we as DBA hate it so much. If you have concerns, as Randy indicated, using the OSA is probably the best solution. If OSA doesn't work for you, try A1. Robert ... View more