When i run my app from visual studio - it works fine, so the connection string is ok.
Whereas when i add the function into Azure and i enter the connection string here :
No matter what I enter the error comes back as :
Here is my latest connection string :
metadata=res://*/CatModel.csdl|res://*/CatModel.ssdl|res://*/CatModel.msl;
provider=System.Data.SqlClient;providerName=System.Data.EntityClient;
provider connection string='data source=xxx.database.windows.net;initial catalog=CatsDB;
user id=xxx;password=!;
MultipleActiveResultSets=True;
App=EntityFramework
Any help would be amazing because i have been testing connection strings for hours...
Related
I use ADO connectionstring to MariaDB in dBase and when the connection is unsuccessful (invalid userid, pwd, port number, IP address, databasename or if the server is not running), I get the MariaDB datasource connector wizard. Once I cancel or complete the wizard (both successfully or unsuccessfully), I get the ADO error into dBase.
Is there a way to disable this wizard and just return the error?
For anyone interested, adding 16 (for NO_PROMPT) to the "option" part of the connectionstring disables the popup.
Just in case anyone is looking for the same option for SQLserver, look here: https://learn.microsoft.com/en-us/sql/ado/reference/ado-api/connectpromptenum?view=sql-server-ver15
oConn.Properties("Prompt") = adPromptNever or any other desired option from the above link
oConn.Open "Driver={SQL Server Native Client 10.0};Server=myServerAddress;Database=myDataBase;"
Dears
Please help me with VS add-in Tfs connection question.
I've wrote VS 2017 plugin that uses TfsTeamProjectCollection class to connect to the tfs server. Tfs server is hosted in the https://dev.azure.com
However on certain computers it fails to connect to the Tfs server.
For example, I've tried to reproduce this and cleared all caches like described here. After clearing/connecting several cycles I've got the following:
VS Team Explorer is connected to the Tfs. I can checkout/checkin files, load history etc.
My add-in fails to connect with 401 non authorized error.
unity test started by VS is able to connect to the same Tfs using the same code
I've created sample console application that uses exactly the same class and method from add-in to connect and it works too.
Here is the source code I'm using to connect:
public override TfsTeamProjectCollection CreateCollection(WorkspaceInfo wi)
{
var s = (overrideConfig ?? Config);
var u = wi.ServerUri;
var vssCred = new VssClientCredentials(); // GetCredentials(s.Vsts);
Logger.Debug("getting collection for url:{0}", u);
TfsTeamProjectCollection tpc = null;
try
{
tpc = new TfsTeamProjectCollection(u, vssCred);
Logger.Debug("authenticating");
tpc.Authenticate(); // 401 non authorized exception here
}
I've tried to add vssCred.Storage = new VssClientCredentialStorage(); before Autheticate() but no luck
Then I've checked network packets using Fiddler application.
It shows the same request packet is sent using unit test, console application and add-in.
But console application and unit test produces initial request
POST
https://dev.azure.com/quipu-cwnet/Services/v3.0/LocationService.asmx
HTTP/1.1
and response is
HTTP/1.1 401 Unauthorized
X-TFS-FedAuthRedirect:
https://app.vssps.visualstudio.com/_signin?realm=dev.azure.com&reply_to=https%3A%2F%2Fdev.azure.com%2F...
Then console and unit test sends packet to the redirect url and asks for user credentials.
When add-in tries to connect to the Tfs server fiddler shows only first POST request and 401 response (with the same X-TFS-FedAuthRedirect header. But there is no redirection. From user side it looks like application freezes for some period after 401 response is obtained and then fails with 401 error.
Both Unit test and add-in assemblies has the same references to the 15.0.0 assemblies like Microsoft.TeamFoundation.VersionControl.Client and related.
I've tried VssConnection but the same
VssConnection connection = new VssConnection(u, vssCred);
connection.ConnectAsync().SyncResult();
var prj = connection.GetClient<ProjectHttpClient>();
var prjCollection = prj.GetProjects().Result; // 401 error here when is executed as VS add-in
foreach (var pc in prjCollection)
Logger.Debug("\tVssConnection project {0} {1}", pc.Id, pc.Name);
I'm using the same user to start VS (and add-in) and console. No elevated permissions.
Is there anything I can do with TfsConnection when used as VS add-in ?
the answer is to execute Authenticate() in the separate thread (non GUI) :crazy
var authTask = Task.Run(() => tpc.Authenticate());
authTask.Wait();
Please note that I'm using VS 2017 15.9.11 and Microsoft.TeamFoundationServer.ExtendedClient.15.112.1
upd1: I've upgraded Microsoft.TeamFoundationServer.ExtendedClient to 15.113.1
it works on my machine but still fails on my colleague machine.
Tfs credentials are working like a charm on both machines:
var tfsClientCredentials = TfsClientCredentials.LoadCachedCredentials(wi.ServerUri, false, false);
var res = new TfsTeamProjectCollection(wi.ServerUri, tfsClientCredentials);
res.EnsureAuthenticated();
despite the fact it is marked as obsolete.
I'm having a problem calling the API's method CompleteSale via eBay_Service .NET SDK (v967) since 2 weeks (02/10).
When the ERP tries to sends some updated information about one order, it receives this Exception:
the underlying connection was closed an unexpected error occurred on a send
so I haven't got a response from the API.
There are more than one strange things:
there are some batch in background, using the same .dll, and they
work fine;
after rebooting the server the first call to "CompleteSale" works fine;
after registering again the .dll via the "regsrv" command, it worked
fine for one day;
all operators that uses the ERP are connected to the server via
remote desktop and all of they notice the problem. Instead, if i
connect from my company's office, all works fine;
I've tried to increase the timeout to 360 sec (from 60 sec) and nothing changed.
The ERP is developed in progress (OpenGL) , so I can't fix with setting "KeepAlive" to "false", setting the certificate explicitly (Tsl1.1 | Tsl1.2) or making other interventions on .net side. I was wrong, it can be done from the source code of the SDK.
i've checked the Security Protocols on the api's servers discovering that the "SSL3" is not longer supported whereas the default value for the ServicePointManager.SecurityProtocol in .NET 2.0 is SSL3.
I've solved the problem by adding this hotfix at the "eBayXmlAPIInterfaceService" class in the SDK's source code:
//768 = Tsl1.1, 3070 = Tsl1.2
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072 |
(SecurityProtocolType)768;
HttpWebRequest http = (HttpWebRequest) WebRequest.Create(this.Url);
http.Method = "POST";
http.ContentType = "text/xml";
http.ContentLength = data.Length;
http.KeepAlive = false;
Probably Microsoft as released an hotfix to correct this problem but the server wesn't updated since 2015.
Moreover i've replicated the .net code in the ABL application in a program that we use to do get/post requestes:
DEF VAR w-tsl10 AS System.Net.SecurityProtocolType
w-tsl10 = CAST(System.Enum:ToObject(PROGRESS.Util.TypeHelper:GetType("System.Net.SecurityProtocolType":U), 192), System.Net.SecurityProtocolType).
ystem.Net.ServicePointManager:SecurityProtocol = w-tsl10.
link to the security protocol verifier: https://www.ssllabs.com/ssltest/index.html
I was working with betfair api and got this issue. After some research I found this
System.Net.ServicePointManager.Expect100Continue = true;
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
This one has me for a while now, I am trying to build a console app that can call a .net web/wcf service SP, the first leg is to get a token from the idP (ADFS4.0) the pasted code was working fine for a whole day, at some point it stopped working with the following error:
SOAP security negotiation with 'https://adfs.domain.in/adfs/services/trust/13/windowsmixed' for target 'https://adfs.domain.in/adfs/services/trust/13/windowsmixed' failed. See inner exception for more details.
The inner error is:
The Security Support Provider Interface (SSPI) negotiation failed.
NativeErrorCode: 0x80090350 -> SEC_E_DOWNGRADE_DETECTED
I have tried /13/windows and /windowstransport as well as the endpoint.
private static GenericXmlSecurityToken RequestSecurityToken()
{
// set up the ws-trust channel factory
var factory = new Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannelFactory(new WindowsWSTrustBinding(
SecurityMode.TransportWithMessageCredential), new EndpointAddress(new Uri("https://adfs.domain.in/adfs/services/trust/13/windowsmixed"), EndpointIdentity.CreateSpnIdentity("adfs#domain.in")));
factory.TrustVersion = TrustVersion.WSTrust13;
var rst = new RequestSecurityToken
{
RequestType = RequestTypes.Issue,
KeyType = KeyTypes.Bearer,
AppliesTo = new System.ServiceModel.EndpointAddress(endpoint_address)
};
// request token and return
return factory.CreateChannel().Issue(rst) as GenericXmlSecurityToken;
}
In my case, for some reason, the ADFS was available over VPN but the AD based authentication bits are not happening over VPN. That's why SEC_E_DOWNGRADE_DETECTED is coming. In a regular non VPN environment things are good.
Also, another observation is once SAML token is generated over a regular enterprise network. Subsequent calls to generate the SAML token are going through as expected even on VPN.
So, if you see this error just check if the network you are in is part of the domain (and not public or private network), for SSPI negotiation.
I am working on Delphi 7, SQL Server 2008 R2 and i am using ADO to connect to database.
My Connection String:
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TESTDataBase;Data Source=TestDataSource
when i make my TADOconnection.Connected to True Connectin string is changing it to
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=TESTDataBase;Data Source=TestDataSource; Use Procedure for Prepare=1;
Auto Translate=True;Packet Size=4096;Workstation ID=MYMachineName;Use Encryption for Data=False;Tag with column collation when possible=False
There are more than 10 applications and i am planning to use the same connection string in all applications.
so when i connect to FirstApplcation i am creating ADO Connection string, saving it in registry or some where so i can use the same connection string for other applications also.
Same user can run more than one application(it can be 2 or 3 or 5 applications).
Here i have 3 questions
1)when i need to share connection?
i mean create the connection string and share the same Connection string(write to registry or some where)
or
create the connection string , connect to database and share the same connection string(write to registry or some where)
2) In my application when i get the shared connection string do i need to connect to database again(TADOConnection.Connected= true)? i think i should connect it again, since it is different application :)
3) For all my applications i open connection at application(main form) form show and i will be closing connection at application(main form) form close.So connection will get close only when application closes and TADOCOnnection.KeepConnection = True. is this create performance issues or burden on database server?
A shared UDL file can be good for sharing a connection. Use the required properties only for your connection string, i.e:
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security
Info=False;Initial Catalog=TESTDataBase;Data Source=TestDataSource
Don't worry about the extra properties that are added by the ADO after you connect. it's the default properties for the specific provider you use (SQLOLEDB.1). The same properties will be set in all your other applications if you use the exact connection string or UDL file (with a common provider).
ADO connections to SQL Server are pooled by default.
You can simply set e.g.
MyConnection.ConnectionString := 'FILE NAME=c:\my_shared_path\shared.udl';
MyConnection.Open;
A good place to hold a shared connection object (TADOConnection) is in a shared Data Module for the entire application.
Open it in the data module or the main form OnCreate event.
The connection is automatically closed once the TADOConnection is destroyed.