Running sdesetup on other database port than default

Question

I have  v.10 ArcSDE on PostgreSQL 8.3 runing on SUSE 64bit. 
Firts instance database running on default port 5432
Second instance database running on port 5532
When I wont to register database on second instance
 sdesetup -o install -d POSTGRESQL -u sde -D database -l /home/sde/keycodes  -i sde:postgresql:10.30.0.31;PGPORT=5532:schema
Show error:
ESRI ArcSDE Server Setup Utility Thu Dec 12 11:31:34 2013
----------------------------------------------------------------
Connection to database 'database' failed.
Connection to test failed(0)
Error creating ArcSDE direct connection (-162)

Does anyone have an idea to solve the problem ?
Thanks to all,
Artur

AndrzejTalarczyk · Answer

Also, make sure that you have put the parameter to the -i switch between quotation marks. The way you have written it, everything after the semicolon will be treated by the command line interpreter as a new command. IMHO your command should look like this:sdesetup -o install -d POSTGRESQL -u sde -D database -l /home/sde/keycodes -i "sdeostgresql:10.30.0.31;PGPORT=5532:schema"

VinceAngelo · Answer

First of all, you need to make sure you're using the right PostgreSQL 8.3 release --
ArcGIS 10.0 supports PG 8.3.8.

Second, you need to specify the port either by using the PGPORT environment variable,
or by editing the etc/dbinit.sde to contain "set PGPORT=5532".   This should unclutter
your command-line down to the minimum (don't specify a '-i' at all -- all 'install' operations
are Direct Connect by necessity, and that '-i' doesn't accept the same parameters).
Note that you need one SDEHOME for each instance to make this work.

Third, starting at 10.0, ArcGIS could be used to create geodatabases, and at 10.1 became
the only way.  You might want to start using the modern tools.

- V

WilliamCraft · Answer

Typically, a -162 error occurs when an invalid database name has been supplied in the connection string.  The specified database name is either not recognized or does not exist on your server.  Can you be sure that the database name is spelled correctly and is valid for the server to which you are connecting?  Were you getting different behavior with the first database instance using the same type of connection string?