Anything and Everything

https://blog.pythian.com/fix-sql-server-to-postgresql-linked-server-error-requested-conversion-is-not-supported/

I ran into an interesting situation when executing a Remote Stored Procedure on Linked   Server using four part query.    Vista-3139 which is a SQL Server 2005 instance is linked to the SERV2003\SQLDUMMY which is a SQL Server 2000 named instance. When I tried to execute a stored procedure: EXEC [SERV2003\SQLDUMMY].SQLAdmin.dbo.sp_ddlevents   Got the following error message. Could not connect to server SERV2003\SQLDUMMY ' because '' is not defined as a remote login at the server. Verify that you have specified the correct login name. I checked the Security settings of the linked server and it was set to “Be made using the login's current security context", which is valid considering that the user has all the permissions to login to the remote SQL server. Then I changed the security context to use a SQL authentication, but still it failed with the similar error message as described above. To troubleshoot this further, I ran

Aliases Description -  https://blogs.msdn.microsoft.com/sql_protocols/2007/01/07/connection-alias/ Configuring Aliases -  https://blogs.msdn.microsoft.com/wwepmcoe/2010/01/07/sql-server-alias-names/

Reporting Service Solutions - here , YouTube video

If the certificate being used on the server was generated using the Legacy Key option in the certificate request form, the private key for that certificate will be stored in Microsoft's legacy Cryptographic API framework. When the web server tries to process requests using its new, Cryptographic Next Generation (CNG) framework, it appears that something related to the RSA private key stored in the legacy framework is unavailable to the new framework. As a result, the use of the RSA cipher suites is severely limited. To avoid the issue, you can try to generate the certificate request using the CNG Key template in the custom certificate request wizard.

A potentially dangerous Request.Path value was detected from the client (*) The * character is not allowed in the path of the URL, but there is no problem using it in the query string: http://localhost:3286/Search/?q=test* It's not an encoding issue, the * character has no special meaning in an URL, so it doesn't matter if you URL encode it or not. You would need to encode it using a different scheme, and then decode it. For example using an arbitrary character as escape character: query = query.Replace("x", "xxx").Replace("y", "xxy").Replace("*", "xyy"); And decoding: query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");

Event ID 36882: The Certificate Received From the Remote Server Was Issued By an Untrusted Certificate Authority. Because authentication relies on digital certificates, certification authorities (CAs) such as Verisign or Active Directory Certificate Services are an important part of TLS/SSL. A CA is a mutually-trusted third party that confirms the identity of a certificate requestor (usually a user or computer), and then issues the requestor a certificate. The certificate binds the requestor’s identity to a public key. CAs also renew and revoke certificates as necessary. For example, if a client is presented with a server’s certificate, the client computer might try to match the server’s CA against the client’s list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and has not been tampered with. The Schannel provider creates the list of trusted certification authorities by searching the Trusted Root Certification Authori