Latest Contributions by VinceAngelo

It is important to understand the concept of operation behind versioning in order to know what happens in implementation.  The documentation goes into the details, but the key thing to keep in mind is that versions are not the important part of the versioning model -- states are.  Versions are only important because they give a name to a state. When you look at the tables in your database, you'll see that INSERTs are done in the "adds" table, and DELETEs are implemented as inserts to the "deletes" table. UPDATEs are implemented as inserts to *both* the adds and deletes tables. Even if all edits are done to the version named "DEFAULT", the same insert-only methodology is used, with the states progressing, and the DEFAULT version advancing to the most recent state. Now, if your state tree is just a long chain of edits without branches, then the reconciliation process will not find any conflicts, and posting is not necessary. You will, however, still need to compress the table to purge the adds and deletes tables of the state changes, and publish the edits into the base table. The only exception to this is when you've requested the "move edits to base" option, which rolls the reconcile/post and compress into the edit operation. Of course, if you never use the features of versioned editing, then shifting to unversioned editing (with only short transactions) might be more efficient. - V ... View more

Contact Tech Support; they're the only folks who might have tools like that. - V ... View more

It sounds like your FGDB was corrupted, and the compress made things worse. - V ... View more

Are you following the install doc for 8.4.1?  I use 8.3.8 and haven't ever tried the postinstall GUI, so I can't really say.  - V ... View more

Most of the tables with GDB_ prefixes (and a couple that aren't) are involved, really.  The geodatabase object model diagram shows the interaction between the ArcSDE tables, but I can't find a reference to that diagram right now.  It's probably somewhere in your Help subsystem (I found the 10.0 model easily on my laptop, but don't have 9.3 readily available). - V ... View more

What platform are you using?  Source for PostgreSQL 8.4.1 and PostGIS 1.4.0 are available on their respective web sites; making Linux builds from source isn't much more than "./configure ; make ; make install".  I'm not adventurous enough to try to make Windows binaries from source. It might be possible that recent binaries would work, but the support for that is more along the lines of "If it works, then it's supported; if doesn't then it isn't". - V ... View more

If you can get to C or Java, you can get to anything, but that doesn't mean you should. Using Python inside a trigger is a bit like using a 737 to deliver mail in the bush -- using ArcPy is more like an Airbus 380. The key to a good trigger is minimalism. You can leave the large clunky app running outside the database, where the initialization and termination costs can be amortized across the application life, and then put the effort into transmitting and queuing the data messages, so that a bulk insert doesn't cripple your server with backlog (the best bet on the server side is a multi-threaded architecture that permits one queuing agent to accept messages in milliseconds, and one or more worker threads to act on the requests -- make sure you have a way to preserve unsatisfied requests in the event of system shutdown before they are completed, and a recovery protocol to restore stability in the event of message loss). A day or two might suffice, if you have a seasoned team of six developers ready to pull a double all-nighter 😉 - V ... View more

Then your only options are: 1) Have the trigger write data to a file, then signal an application     to execute the instructions in the file (or if the data is small     enough, just signal with the data). 2) Re-architect the database so that the trigger can populate a     row which participates in a view to re-use the source geometry. If you have a developer skilled in interprocess communications, solution 1 may only take a week or two to implement (mostly ArcSDE 'C' API spin-up time).  If concurrency isn't an issue, then a frequently-running application could execute the inserts (certainly for prototype purposes); I could code that app in days, but I have 20 years experience in real-time application development, 15 years with the ArcSDE 'C' API, and a very deep bag of tricks (aka 'se_toolkit') to speed development. It's a shame, since this could be trivially accomplished with any RDBMS that wasn't SQL-Server 2005 (2008, Oracle, Informix, DB2, or PostgreSQL). - V ... View more

It's not possible with SQL-Server 2005, but it's *very* easy with SQL-Server 2008 using GEOMETRY types. - V ... View more

What do you want the trigger to do? How many feature are involved in the table? How often would the trigger be executed? Generally speaking, triggers should be *very* light applications -- if it can't be executed in a few milliseconds (ideally, certainly under a second per event), you probably should look at using a different mechanism. - V ... View more

Yes and no.  If I recall, there are four tables at ArcSDE 9.x, and at 10.0 they're stored in XML. - V ... View more

That's just a warning that the hostname string exceeds the display format available to 'sdemon' for one-line display.  It's probably not related to the geocoding error. - V ... View more

Mark - If the "User Information" tab is returns the same information that 'sdetable -o list_grantees' does (using  SE_table_get_grantee_privilege_list) against 10.0 servers, then it's trying to use a capability that does not exist in pre-10.0 servers (see #NIM062845).  - V ... View more

The SeRelease object (SE_RELEASE in 'C') will tell you the properties of the connected server, but the 'C' API doesn't have a function to return the client release, and I doubt the Java API does either (which is why I name my API home directories with the version and service pack [and sometimes patch level]). - V ... View more

A static database clone is just another database, as far as an ArcSDE application server is concerned.  You should probably set the READONLY flag to TRUE immediately after starting the giomgr, though, since changes wouldn't be reflected in later snapshots. The same approach is used to start a service on a Unix host, regardless of what login is used to start it: 1) Set the SDEHOME, PATH, and shared library path variables for both the database client and the ArcSDE application server 2) Set any database environment variables (like ORACLE_SID or TWO_TASK) needed to make connection 3) Capture the password for the '-p' flag 4) Issue the 'sdemon -o start' command Shutdown is the same, though step 2 isn't required. There's an esri.com forum post on this topic using my 'userproxy' utility, and the current se_toolkit release has an 'arcsde' Linux boot script under the samples directory without userproxy (it invokes itself with an 'su').  An experienced Unix admin could help you alter either for your needs. - V ... View more