Another "Failure to access the DBMS server."

[PaulHuffman]

I have new hardware running  SQL Server 2012 R2 and I'm trying to create my first Enterprise geodatabase on it but all I can get back using the two client machines I have running Desktop 10.3.1 and SQL Native Client is "Failure to access the DBMS server"  Don't understand this because I didn't have this problem with my install at a different location a couple months ago, and I just completed the instructor led course Deploying and Maintaining a Multiuser Geodatabase earlier this week.

My DBA set up the new servers as virtual servers on the same unit.  From my DBA I got:

  NSQL 192.168.3.222

  Administrator: *********

  SQL Server instance MSSQLSERVER

  sa: *********

  NSMAP 192.168.3.223

  Administrator: ************

But when I try to create my first geodatabase, I get Failure to access the DBMS server. If the SQL Native Communications driver were missing, or wrong, I think I would get a different error message,  something about communication to the SQL server. (How does one tell if the SQL Native client is installed on a client PC? Don't see it in Data Sources.)  I wondered if Windows firewall was blocking, but I turned off public and private firewall temporarily on the client NSMAP and the SQL Server NSSQL, no change. Also tried the trick to modify the host file on the client machine to resolve the SQL host name, no change.

I pulled the Create Enterprise Geodatadata tool results into a python window to make it easier to repeat iterations with minor changes. But it also makes it easy to copy and paste my attempt as text.

>>>

arcpy.CreateEnterpriseGeodatabase_management(database_platform="SQL_Server",

instance_name="MSSQLSERVER", database_name="Orthos", account_authentication="DATABASE_AUTH", database_admin="sa", database_admin_password="**********", sde_schema="SDE_SCHEMA", gdb_admin_name="sde", gdb_admin_password="sde", tablespace_name="", authorization_file="C:/Program Files

(x86)/ESRI/License10.3/sysgen/keycodes")

Runtime error Traceback (most recent call last): File "<string>",

line 1, in <module> File "c:\program files

(x86)\arcgis\desktop10.3\arcpy\arcpy\management.py", line 4857, in

CreateEnterpriseGeodatabase raise e ExecuteError: Failure to access

the DBMS server Failed to execute (CreateEnterpriseGeodatabase).

Maybe my DBA or I have made a typo. But this has me wondering now does the db account sde need to be created first? How does the RDMS know that the sde account has a password of sde?  Or is there something wrong with my network topology.  I can't ping the SQL server from my Desktop or from the neighboring server NSMAP, but I can Remote Desktop to both NSQL and NSMAP.  

[AnthonyKobah]

Hi Paul,

I will also check if TCP/IP is enabled or not on the machine running the SQL Database.

Start Menu --- Microsoft SQL Server 2012 -- Configuration Tools --- SQL Server configuration Manager.

[AnthonyKobah]

That might not be related. Appears you are able to connect to the database but can't create the DB.

[PaulHuffman]

Found that the SQL Server Browser was disabled,  so I started it, and set it to automatic.  Found that the TCP/IP was enabled for all three.  But still getting "Failure to access the DBMS server Failed to execute (CreateEnterpriseGeodatabase)"  

Doesn't the fact that I can't ping the SQL server host from either of my two client machines mean that I have a network problem?  Can't even ping NSQL it from the ArcServer virtual server, NSMAP, that is sitting in the same box.

[George_Thompson]

I would say yes, there is a network/SQL Server configuration issue if you cannot ping/telnet or connect via SSMS from other client machines to NSQL.

I would recommend working with the DBA that did the installation of the SQL Server instance.

Hope this gets you moving in the right direction.......

[PaulHuffman]

The heck of it is that the DBA never really was in favor of this installation and now seems to be reluctant to help.  The last message from him was "All I did is a complete install of SQL server, and create a system administration account. The rest is up to you."  We've had a rocky relationship lately, with him accusing me of changing MySQL passwords without notifying him, and running his complaints up the COC, but the accusations have turned out to be untrue.  So if I finally find out that this SQL server was not completely implemented, and if I were a spiteful man, I might cast aspersions his way.  But I've found the best policy is generally charity and forgiveness, and I'm not even Christian.

[JohnBrockwell]

Install ArcGIS Desktop Advanced on the SERVER running MSSQL to administer your enterprise geodatabase. Create enterprise geodatabase using localhost/instancename. This is a workaround but most GEODB admins are installing ArcGIS desktop on the server. It's not a problem if you have a concurrent license.

[PaulHuffman]

Thanks John.  I thought about this work around,  but even if I create the database with Desktop on the server won't client machines still be unable to make a database connection if I have an underlying network problem?

[JohnBrockwell]

Open the port for SQL (1433) and make sure your users have the SQL Client installed on local workstations and they will be able to consume SDE Feature Classes

[PaulHuffman]

When trying to get to my Desktop 10.3.1 install files on my network,  I discovered that Network discovery was turned off on my SQL machine, NSQL. I turned that back on, and discovered that now my client machines can ping the SQL server by IP address.  I was momentarily excited that I had found the reason that client machines couldn't run Create Enterprise Geodatabase.  but got the same result from client machines.  So I continued to install Desktop 10.3.1 on NSQL, got a desktop license over my network, installed msodbcsql on NSQL,  ran Create Enterpise Geodatabase with a keycode file pulled across my network, but I still got "Failure to access the DBMS server". 

[George_Thompson]

I think that it might be a good idea to create a case with Esri Support so they can review all the information.

Based on the latest information there is something in the connection or the SQL Server instance.