I deployed a new cosmosDB with mongo and I have an appservice also in the azure. The appservice is a simple php application which connect to a collection (which is in cosmosDB). It works perfect except a connection problem. Cosmosdb throws sometimes this: No suitable servers found (serverSelectionTryOnce set): [connection closed calling ismaster on 'http://apidb.documents.azure.com:10250 '].
What could be the problem? Need to increase RU or need to change consistance settings?
PHP: 7.0.18, mongodb driver: 1.2.8, libmongoc version: 1.5.5 (as I read this problem should be fixed in 1.2.0 mongodb driver version)
Thanks in advance!
UPDATE:
If I remove repliceSet option from the connection string (azure said this option is recommanded), throws this error much less.
Can you try setting serverSelectionTryOnce = false as per http://php.net/manual/en/mongodb-driver-manager.construct.php and retrying your use case. As per your current setup, a single failure in isMaster request will cause the application to fail with the above mentioned error.
If you are still hitting the same error, please send the exact error message (and preferably the MongoLog http://php.net/manual/en/class.mongolog.php) to askcosmosmongoapi [at] microsoft [dot] com
Related
I'm trying to connect to an Azure db using pyodbc and keep getting this error.
My connection string:
"Driver=ODBC Driver 17 for SQL Server;Server=company.database.windows.net;Authentication=ActiveDirectoryPassword;Database=My_Database;UID=DOMAIN\UserName;PWD=********;"
Each time I connect it returns error The server has not found anything matching the requested URI
The strange thing is that when I try to connect with these credentials from inside SSMS, the error I get is Windows logins are not supported in this version of SQL Server.
All the other questions with this error are on web apps and html pages, so I'm very stuck.
I figured it out.
The problem was that I was using UID=DOMAIN\UserName;. When I switched it to UID=username#domain.com; the connection worked.
Hope this helps someone else with the same problem - there are not many resources on this error.
Cross-posting with this on the IBM forums: https://www.ibm.com/mysupport/s/forumsquestion?id=0D50z00006egDnsCAE. Follow-up question located here: Having trouble connecting to iSeries from .NET Core
Hi all,
I'm very new to this whole thing, so let me know if there's any info which would help, that I'm not providing.
At the moment I'm just trying to get the very basics working - getting the connection to open. I have a stripped-down .NET Core project, which is simply exposing a button I can press that opens a connection for DB2. My code is as follows:
using IBM.Data.DB2.Core;
...
DB2Connection DB2Connection = new DB2Connection(connectionString);
DB2Connection.SystemNaming = true;
DB2Connection.Open();
My connection string is as follows:
"Server=###.###.###.###;Database=AAAA;UID=BBBB;PWD=CCCC;LibraryList=DDDD,EEEE;"
I'm getting the following exception:
IBM.Data.DB2.Core.DB2Exception (0x80004005): ERROR [08001] [IBM] SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP". Communication API being used: "SOCKETS". Location where the error was detected: "###.###.###.###". Communication function detecting the error: "connect". Protocol specific error code(s): "10061", "*", "*". SQLSTATE=08001
I really don't know how to proceed from here. For context - I'm using "IBM Navigator for i" to query the info directly, and that works just fine for the IP, User ID, and Password I used above.
I've done some reading up, and attempted a few different solutions, but none really helped. I did see that in "Integrating DB2 Universal Universal Database for iSeries with for iSeries with Microsoft ADO .NET", it suggested looking in the Work Management section of the navigator, and check under Server Jobs to see whether there was any added info - however, it does not appear there is anything there to see.
I do understand that I may require a license for this connection to work properly, and accept that if that ends up being the problem, I'll need to get the license - but I don't think I've reached that stage yet. For now I just want to make sure the connection itself works properly.
Any help or insights are greatly appreciated. Thank you.
The symptom SQL30081N with 10061 was resolved by including the PORT=xxx; in the connection string, where xxx is the correct TCP/IP port number on which the Db2-for-i-series is listening for connections.
I have a asp.net application deployed to Azure websites connecting to Azure SQL Database. This has been working fine for the last year, but last weekend I have started getting errors connecting to the database giving the following stacktrace.
[Win32Exception (0x80004005): Access is denied]
[SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)]
This error comes and goes staying a few hours and then goes away for a few hours. The database is always accessible from my machine.
A few things that I have tried are:
Adding a "allow all" firewall rule (0.0.0.0-255.255.255.255) has no effect
Changing the connection string to use the database owner as credential has no effect.
what does have effect is to change the azure hosting level to something else. This resolves the issue temporarily and the website can access the database for a few hours more.
What could have have happened for this error to start showing up? The application hasn't been changed since August.
EDIT:
Azure support found that there was socket and port exhaustion on the instance. What the root cause for that is, is still unkown.
Craig is correct in that you need to implement SQLAzure Transient Fault Handling. You can find instructions here: https://msdn.microsoft.com/en-us/library/hh680899(v=pandp.50).aspx
From the article
You can instantiate a PolicyRetry object and wrap the calls that you
make to SQL Azure using the ExecuteAction method using the methods
show in the previous topics. However, the block also includes direct
support for working with SQL Azure through the ReliableSqlConnection
class.
The following code snippet shows an example of how to open a reliable
connection to SQL Azure.
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling;
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.AzureStorage;
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure;
...
// Get an instance of the RetryManager class.
var retryManager = EnterpriseLibraryContainer.Current.GetInstance<RetryManager>();
// Create a retry policy that uses a default retry strategy from the
// configuration.
var retryPolicy = retryManager.GetDefaultSqlConnectionRetryPolicy();
using (ReliableSqlConnection conn =
new ReliableSqlConnection(connString, retryPolicy))
{
// Attempt to open a connection using the retry policy specified
// when the constructor is invoked.
conn.Open();
// ... execute SQL queries against this connection ...
}
The following code snippet shows an example of how to execute a SQL command with retries.
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling;
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.AzureStorage;
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure;
using System.Data;
...
using (ReliableSqlConnection conn = new ReliableSqlConnection(connString, retryPolicy))
{
conn.Open();
IDbCommand selectCommand = conn.CreateCommand();
selectCommand.CommandText =
"UPDATE Application SET [DateUpdated] = getdate()";
// Execute the above query using a retry-aware ExecuteCommand method which
// will automatically retry if the query has failed (or connection was
// dropped).
int recordsAffected = conn.ExecuteCommand(selectCommand, retryPolicy);
}
The answer from Azure support indicated that the connection issues I was experiencing was due to port/socket exhaustion. This was probably caused by another website on the same hosting plan.
Some answers to why the symptoms were removed by changing hosting service level:
Changing the hosting plan helped for a while since this moved the virtual machine and closed all sockets.
Changing the hosting plan from level B to level S helped since azure limits the number of sockets on level B.
We have migrated our Oracle database to 12c from 11g.
We have a legacy application running in Java 1.5 and using ojdbc14.jar.
Our application is not able to create connection to database error saying :
java.sql.SQLException: ORA-28040: No matching authentication protocol
I reffered to answer ORA-28040: No matching authentication protocol exception, and tried to upgrade my ojdbc14.jar to ojdbc6.jar.
I now have a different error message saying :
error: OracleCallableStatement is not public in oracle.jdbc.driver; cannot be accessed from outside package
import oracle.jdbc.driver.OracleCallableStatement;
^
error: OracleTypes is not public in oracle.jdbc.driver; cannot be accessed from outside package
cstmt.registerOutParameter(3,oracle.jdbc.driver.OracleTypes.CURSOR);
^
Ant build file :
<javac srcdir="${src}" destdir="${classes}" source="1.5" target="1.5">
<classpath refid="cpath" />
</javac>
Not sure what exactly we should do to get the application working.
I had the same error with 2 different applications recently:
a Java 7 app on Tomcat 7 using odbc6.jar with Oracle 12 c database.
a legacy ASP application with Oracle 12 c database.
The second solution mentioned in the
same post you referred to - worked well for us.
Workaround: Set SQLNET.ALLOWED_LOGON_VERSION=8 in the oracle/network/admin/sqlnet.ora file.
We worked with our DBAs to set the above option on the sqlnet.ora on the database server. This resolved our issue. I hope it helps someone.
I faced the same error.
Got it resolved by without removing ojdbc14.jar.
step 1 : set SQLNET.ALLOWED_LOGON_VERSION=8
Step 2 : change
Connection conn = (Connection) DriverManager.getConnection("jdbc:oracle:thin:#server:port:sid", "username", "passwrd");
to
java.sql.Connection conn = DriverManager.getConnection("jdbc:oracle:thin:##server:port:sid", "username", "passwrd");
It will works!
After migrating from Oracle 11 to Oracle 12.
In my case lib directory had both OJDBC14.jar & OJDBC8.jar.
After removing older OJDBC14.jar it worked for me.
I had a problem connecting to DB after migration to ORACLE 12c.
The error was:java.sql.SQLException: ORA-28040: No matching authentication protocol.
After setting this parametar SQLNET.ALLOWED_LOGON_VERSION=8 it was solved.
Thank you very much
If you are migrating your application to ojdbc6, one probable reason would be your old classes (compatible to old ojdbc version) might not be getting the class OracleTypes. Easiest way would be changing import statement from import oracle.jdbc.driver.OracleTypes; to import oracle.jdbc.OracleTypes; from the classes where you are getting the error.
I was getting ORA-28040 in Sqldeveloper (ver. 1.5.5) for all connections. I set SQLNET.ALLOWED_LOGON_VERSION=8 but the error didn't go away. Then I enabled "Use OCI/Thick driver" under Tools->Preferences->Database->Advanced Parameters. That did the trick.
The main problem is that the JDBC thin client of the 10g uses the
SHA-1 authentication protocol, this protocol is not allowed in the
12c, so it gives the error.
In my Oracle I could not find the sqlnet.ora file so I had to create it with the command:
vi $ORACLE_HOME/network/admin/sqlnet.ora
And I added the following:
SQLNET.ALLOWED_LOGON_VERSION=10
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=10
SQLNET.ALLOWED_LOGON_VERSION_SERVER=10
SQLNET.ALLOWED_LOGON_VERSION=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
SQLNET.AUTHENTICATION_SERVICES = (NONE)
So I had to stop and start the listener:
lsnrctl stop
lsnrctl start
Finally, I restart the database.
This should only be a workaround
We had this error when we moved from 11g to 12c, I am able to get correct response through tnsping "servername" (this is the first step that we need to check through cmd).
After this we realize that database server is enable to handle only 64bit request (In my case I was using WinSQL and it always check for 32bit).
So to correct this, ask your admin to eanble server for 32 bit request as well or you can move to SQL developer which work for me.
I'm getting the following error when using the Database Publishing wizard to script a SQL Server Express database for deployment. I have googled for hours unsuccessfully. Anyone had this isssue or know how to solve it?
Timeout expired. The timeout period
elapsed prior to obtaining a
connection from the pool. This may
have occurred because all pooled
connections were in use and max pool
size was reached.
Is the database held remotely? - Have you checked firewall settings...?
The error is what it says it is...it's timed out trying to connect.
Make sure you can connect via other means (SQL Management Studio, the app itself). Check the connection string, even try copying the database locally and scripting it that way.
So I downloaded the latest Database Publishing Wizard and it seems to work :-)