SDE and ArcMap Desktop interoperability by version? (SDE 10.1, ArcMap 10.0 and 10.1)

4687
14
10-09-2012 11:59 AM
howardfoster
Emerging Contributor
Hello all,

I have successfully installed ArcSDE 10.1 for postgres (PostgreSQL) on both Linux and Windows machines.  From ArcMap 10.1, these work fine, but I�??m having problems writing layers from ArcMap 10.0 to these databases, which leads me to wonder if you can�??t write from Desktop clients version 10.0 to SDE 10.1�??is this true?  Or did I do something wrong.  I remember seeing a table of Desktop and SDE interoperability by versions with entries something like ... read+write, read-only, <blank=none>.  Can someone give me a pointer to this table?

If I did something wrong, then I can report error messages, etc, plus results of interoperabiliy experiments.

Any pointers appreciated, thanks for your help,
-H
0 Kudos
14 Replies
DanielMrvos
Deactivated User
ArcSDE application services can only run in one database (can't connect to multiple databases
through one service).

What values are you placing in the various connection parameters at 10.0 SP5?  Are you using
Direct Connect or an application server port?

What PostgreSQL client libraries are you using on the various hosts?

- V


Heya,

to clarify things a little bit here is the complete setup:


SDE server (Linux64):

-- /etc/services:
db1        6629/tcp
db1        6629/udp
db2        6630/tcp
db2        6630/udp

-- $SDEHOME/etc/services.sde

db1        6629/tcp
db2        6630/tcp

-- $SDEHOME/etc/dbinit_db1.sde

set PGHOST=/var/run/pgsql
set SDE_DATABASE=db1

-- $SDEHOME/etc/dbinit_db2.sde

set PGHOST=/var/run/pgsql
set SDE_DATABASE=db2


PGHOST=/var/run/pgsql SDE_DATABASE=db1 sdemon -o start -i 6629
PGHOST=/var/run/pgsql SDE_DATABASE=db2 sdemon -o start -i 6630


Connection Properties db1 (ArcCatalog 10.0):

Server: <address of db server>
Service: 6629
Database: db1
Database Authentication:
         Username: sde
         Password: <sde password>

Connection Properties db2 (ArcCatalog 10.0):

Server: <address of db server>
Service: 6630
Database: db2
Database Authentication:
         Username: sde
         Password: <sde password>

Connection Properties db1 (ArcCatalog 10.1):

Database Platfrom: Application Server
Server: <address of db server>
Service: 6629
Database Authentication:
         Username: sde
         Password: <sde password>
Database: db1

Connection Properties db2 (ArcCatalog 10.1):

Database Platfrom: Application Server
Server: <address of db server>
Service: 6630
Database Authentication:
         Username: sde
         Password: <sde password>
Database: db2

With 10.1 clients everything works normal. With 10.0 I can't establish a connection. For instance if I try to connect to db1 I get the same error message as hfoster for db2.


I don't use any client libraries because until 10.0 they weren't needed for SDE connections. And for 10.1 it works without client libraries.

Regards...
0 Kudos
VinceAngelo
Esri Esteemed Contributor
I always use multiple SDEHOMEs for multiple instances, partially because
I don't have the patience to work out how the files need to be named in
oreder to run multiple instances out of one.  But I don't think your setup
is correct:
1) ArcSDE doesn't use UDP, so there's no reason to have duplicate
service name entries
2) If you do use one SDEHOME, your "-i" parameter should be the
service name (dbN), not the port number (so it finds the dbinit file)

I don't see how the 10.1 clients can be connecting to the right database,
but if they do, there's no apparent reason why the 10.0 clients should
not have the same behavior.

First off, use the service name in your 'sdemon' directives.  If it still fails,
try using two different SDEHOME  directories.  If that fails, contact Tech
Support.

- V
0 Kudos
DanielMrvos
Deactivated User
I always use multiple SDEHOMEs for multiple instances, partially because
I don't have the patience to work out how the files need to be named in
oreder to run multiple instances out of one.  But I don't think your setup
is correct:
1) ArcSDE doesn't use UDP, so there's no reason to have duplicate
service name entries
2) If you do use one SDEHOME, your "-i" parameter should be the
service name (dbN), not the port number (so it finds the dbinit file)

I don't see how the 10.1 clients can be connecting to the right database,
but if they do, there's no apparent reason why the 10.0 clients should
not have the same behavior.

First off, use the service name in your 'sdemon' directives.  If it still fails,
try using two different SDEHOME  directories.  If that fails, contact Tech
Support.

- V


Heya,

thx for the reply. Tried it with instance name, same problem. Will try the multiple SDEHOME approach during the weekend.

Tried our regional Tech Support but they only gave me the afformentioned bug report or to use direct connections, but I'm not as ambitious as to change the connection properties and installations on 30+ computers 🙂

Regards...
0 Kudos
MarcoBoeringa
MVP Alum
1) ArcSDE doesn't use UDP, so there's no reason to have duplicate
service name entries


Vince, this was my understanding always too, but looking at the 10.1 Help regarding Starting a remote ArcSDE service on Linux or UNIX, I now read this:

"2. As the root user, duplicate the service name in the /etc/services file as a User Datagram Protocol (UDP) entry that uses the same port number on both the local and remote servers.

# \etc\services
esri_sde 5151/tcp
esri_sde 5151/udp

3. As the root user, update the /etc/inetd.conf file. Add this line to the bottom of the file.

<ArcSDE instance> dgram udp wait <owner of ArcSDE home>
<$SDEHOME>/bin/sderemote iomgr_inetd
<$SDEHOME><ArcSDE instance>"


The UDP connection seems necessary for running the ArcSDE service from a remote server, so in case it is installed on a physically separate server from the database server it uses the data from, as written on this Help page.

P.S. Just to clarify for other Forum users reading this thread...
0 Kudos
VinceAngelo
Esri Esteemed Contributor
UDP is used for remote server start, but I've never seen a need to use that feature.
Cluttering the services file with unused references isn't best practice.

- V
0 Kudos