Latest Contributions by VinceAngelo

Just because one of the resource libraries is linked /MD doesn't mean your application needs to be /MD.  I just used VS 2008 to create an /MT application that uses the /MD FileGDBAPI.lib -- It does create a FileGDBAPI.dll dependency, but the license permits redistribution of the  DLL.  The plus here is that release of future SPs to the API wouldn't always require recompilation of the apps that use it. - V ... View more

The difference in length/area is due to spherical unit awareness (e.g., not linear decimal degrees). It's probably time to work with Technical Support to open an incident. - V ... View more

Can you provide the full 'sdelayer -o describe_long' output for the layers of Case1 and Case2? Does the result change if you define the layer to have the SQL constraint "xxx_ID = 1"? How many rows in the table? What does a SQL query of the table return for each table (first row, if necessary). Note that your initial assertion of "need to use the Geography type ... that is the data type that supports it" is not completely accurate.  GEOMETRY would also support the same data, but without the single hemisphere limitation (and with a change in the result of area/length calculations). - V ... View more

The real reason the query fails will be reflected in the logfiles in SDEHOME\etc. Odds are, it will be one of the topology errors of the SgShape library ("ring crosses ring" "no area" "too few points" "coordinate out of bounds"). Your command-line registration may create a very different coordinate reference than using Desktop would.  You can see this by using 'sdelayer -o describe_long'.  It's not only the coordinate system that matters, but also the origin and scale. For best practice, load the GEOGRAPHY table as a user other than SDE (this user should be reserved for instance administration, with a very closely held password).  You don't need to specify the user during layer registration, since it must be done as the owner. - V ... View more

To close this up, Direct Connect replaces the 'gsrvr' daemon with a DLL running the equivalent instructions in a local thread of the client process.  You can use Direct Connect for all command- line utilities *except* 'sdemon', since this utility manages interaction with the application server (giomgr process) and never creates a connection. - V ... View more

Doh. I just re-read your post, and yes the 64-bit ArcSDE for SQL-Server libraries are conflicting with the 32-bit ArcSDE for Oracle (that's what the SG.DLL entrypoint error was about). When it comes down to it, Windows just doesn't have the same level of flexibility as Unix to handle 32-bit and 64-bit applications at the same time.  Trying to do too many things on a single Windows box often causes trouble. You might be able to work around the 32/64 DLL conflicts by using a different  login for the ArcGIS service, so it can have a PATH which is different from the 64-bit ArcSDEs for both Oracle and SQL-Server, or you can install a 32-bit ArcSDE for SQL-Server and run all 32-bit apps (except for the 64-bit SQL-Server itself), or you can use *only* Direct Connect for accessing the Oracle ArcSDE database (it's not always necessary to run an application server), but at this point, running 32-bit AGS, 32-bit Oracle Client, 64-bit Oracle Client, 64-bit SQL-Server, 64-bit ArcSDE for Oracle, *and* 64-bit ArcSDE for SQL-Server on a single host may just be a bridge too far. - V ... View more

ArcGIS (both desktop and server) is [presently] a 32-bit application. *All* operating systems supported by ArcSDE require homogeneous architectures for dynamic libraries (32-bit app, 32-bit DLL; 64-bit app, 64-bit DLL), so "DC works but AS doesn't" would be expected with 32-bit client, 32-bit AGS, and 64-bit SDE. "ORA2 SDEHOME" was my shorthand for "the SDEHOME to operate with the ORA2 instance." The fact that no log was written could have been because the first instance already on the host was also Oracle ("ORA2" vice "ORA1"?), and the 'sdeservice' command was using the other SDEHOME\etc.   It may take a reboot to clear the deleted Windows service. Vince's First Law of Compatibility: For optimal stability, the application software should have been released after the server software, which should have been released after the operating system (tOS < tRDBMS < tGIS). [I made sure I knew my answer before posting the "second" law] Check your PATH variable for alternate SG.DLL locations -- Did you copy the 64-bit DLLs into Oracle\bin for ST_GEOMETRY support? - V ... View more

64-bit ArcSDE cannot function with a 32-bit Client (the DLL search fails when a DLL with the right name but wrong wordsize is found). It you have a 32-bit Oracle Client for 32-bit ArcGIS, you should be using a 32-bit ArcSDE Server. This isn't a bad thing -- In my testing, 64-bit ArcSDE did not provide a performance benefit over 32-bit ArcSDE on either 64-bit Windows 2003 Server or RedHat Linux 4/5 (x64). The one time I attempted to have both 32-bit and 64-bit Oracle client installs with both 32-bit and 64-bit ArcSDEs on an x64 2003 host, I toasted my registry so badly I had to have the virtual machine re-imaged. Note that ArcGIS 10.1 will be mostly 64-bit, so at that point you'll have more reason to run 64-bit ArcSDE with a 64-bit Oracle Client. - V BTW: You can/should apply the 10.2.0.4 patchset to your 10.2.0.3 client, since Vince's Second Law of Compatibility says "In a client-server architecture, always run your clients at least even to the server release" (a little ahead is okay, but behind is asking for trouble). PS: If you have multiple ArcSDE application servers running, you really should have multiple SDEHOME locations. ... View more

This is written for Oracle, but I expect it will work for SQL-Server too. http://resources.arcgis.com/content/kbase?fa=articleShow&d=36459 - V ... View more

UDP is not used in the ArcSDE client/server connection protocol. Is your Oracle client 32-bit or 64-bit? Is your ArcSDE install 32-bit or 64-bit? Does the SDEHOME reported by sdeservice -o list correspond to the ORA2 SDEHOME? - V ... View more

It *isn't* necessary that the Oracle server have a services entry, just good practice to prevent port collision. It's probably a mistake to treat service names and ports as if they were interchangable, especially during service creation (it's often true on the client side, but not on the server).  Try using the service mnemonic for both 'sdeservice -o create' and  'sdemon -o start'. - V ... View more

In my experience, when it's an issue, it's always an issue, but it isn't always an issue (the same data in two different tables behaved differently).  We deployed with a phantom table: CREATE VIEW table AS SELECT /* +INDEX(table_alt table_spx) */ * FROM table_alt even though the SDO_FILTERed query against the 'table_alt' performed a millisecond faster (9ms to 10ms) in production; the original 'table' (much of the same data) was returning in 43000ms. - V ... View more

1) The 'DB_Admin_password' is the SDE user password 2) No. 3) In a "Remote Server" configuration, no ArcSDE service is created on the Oracle server. The DBA can help you make sure that your client install is correct (it should be the same release as the server [10.2.0.4, in this case]), that your tnsnames.ora is correct (via 'tnsping'), and that you can successfully connect to the server via SQL*Plus after setting the LOCAL environment variable (the dbinit.sde should have the same LOCAL [not ORACLE_SID] contents). 4) There certainly is a way to define which port to use -- the "-i <service>" parameter of 'sdeservice'.  You must edit the %SystemRoot%\system32\drivers\etc\services file to map the mnemonic to a port number.  It's not required that all hosts in your network have the same services file, but it is a good idea.  I typically run 15-20 different services on my networks at home, office and client sites; it just takes a little effort to set up a naming convention appropriate for the network, then copy/paste the 5151->???? entries into the services file on each host. 30-sec connection timeouts are generally due to a bad hostname/port combination, so you want to be sure your LOCAL is pointing to a correct tnsnames.ora entry. It would probably be best to start an incident with Tech Support so they can walk you through this configuration (it's tricky the first time, but by the third time you won't even need the documentation).  - V ... View more

This seems to be a rather significant bug.  Please contact Tech Support so that it can be fixed as soon as possible. A version is only a name for a state in the state tree.  There is no envelope property on states, but there is on layers, and ArcGIS updates the layer envelope after each edit session.  Even if you delete the offending shape, the delete operation does not shrink the layer envelope (to do so is not nearly as simple as expanding it).  You can however reset the layer envelope with: sdelayer -o alter -l table,geomcol -E -180,-90,180,90 -s server -i port -u owner -p pass - V ... View more

It's time to open an incident with Tech Support. Be sure to provide them the exact versions of software (both Esri and database., to the service pack or patch level). They'll need a copy of the dataset and the exact steps you're taking as well. - V ... View more