Showing posts with label standalone. Show all posts
Showing posts with label standalone. Show all posts

Thursday, March 8, 2012

Connection failure on standalone MSDE installtion when network is lost

Scenario -
On a standalone installation i.e client and SQL server are on same
machine, if network connection is lost while preparing SQL server
connection through client application, then SQL connection could not be
established. This was detected only on few machines. The configuration
details are:
OS : Windows 2000 SP 4 with MSDE
Error : MSVC exception occurred. This is not consistent. Some times it
throws error in sql server connectivity DLLs.Check local security policies on client machines that screw up. I had this
probelem recently.
<shridhargune@.hotmail.com> wrote in message
news:1122392145.762770.32950@.g49g2000cwa.googlegroups.com...
> Scenario -
> On a standalone installation i.e client and SQL server are on same
> machine, if network connection is lost while preparing SQL server
> connection through client application, then SQL connection could not be
> established. This was detected only on few machines. The configuration
> details are:
> OS : Windows 2000 SP 4 with MSDE
> Error : MSVC exception occurred. This is not consistent. Some times it
> throws error in sql server connectivity DLLs.
>

Connection failure on standalone MSDE installtion when network is lost

Scenario -
On a standalone installation i.e client and SQL server are on same
machine, if network connection is lost while preparing SQL server
connection through client application, then SQL connection could not be
established. This was detected only on few machines. The configuration
details are:
OS : Windows 2000 SP 4 with MSDE
Error : MSVC exception occurred. This is not consistent. Some times it
throws error in sql server connectivity DLLs.
Check local security policies on client machines that screw up. I had this
probelem recently.
<shridhargune@.hotmail.com> wrote in message
news:1122392145.762770.32950@.g49g2000cwa.googlegro ups.com...
> Scenario -
> On a standalone installation i.e client and SQL server are on same
> machine, if network connection is lost while preparing SQL server
> connection through client application, then SQL connection could not be
> established. This was detected only on few machines. The configuration
> details are:
> OS : Windows 2000 SP 4 with MSDE
> Error : MSVC exception occurred. This is not consistent. Some times it
> throws error in sql server connectivity DLLs.
>

Tuesday, February 14, 2012

Connecting to the SQLEXPRESS on your computer

How do I connect to the SQLEXPRESS installed on my computer without network connection (as a standalone computer)?

Thanks.

hi,

local connections are usually performed via shared memory, so you do not require network protocols to be enabled to connect to a local instance..

what kind of problems are you experiencing? you usually generate a connection string like those provided in http://www.connectionstrings.com/, thus something similar to

Data Source=(Local)\NamedInstanceName;Initial Catalog=the_database;Integrated Security=SSPI;

regards

|||

I was having problems connecting to my local PC even after creating a security user and using the correct connection string. Turns out that I needed to go into SQL Server Configuration Manager and enable TCP/IP Protocol. Everything was disabled by default. Start, All Programs, Microsoft SQL Server 2005, Configuaration Tools, SQL Server Configuration Manager (local), SQL Native Client Configuration, Client Protocols, Right Click TCP/IP and select properties to enable.

|||

Hi Cecook,

You were probably connecting through MDAC. This is fine and fully supported, but you do have to enable TCP/IP in order to connect with legacy providers. If you use the new SQL Native Client (SNAC) you can connect directly to SQL using Shared Memory and you don't need to enable TCP/IP for local connections. SNAC also supports ODBC and OLEDB as well.

Note: You always have to enable TCP/IP or Named Pipes to connect to SQL from a remote client.

Mike

Sunday, February 12, 2012

Connecting to SQL Server from IIS in DMZ

My Web Server is standalone, in a DMZ and not a member of the domain the SQL server belongs to. The SQL server is internal and behind a firewall.

I followed the recommendations on Microsoft's website Using the ASP.NET process identity
and local mirrored ASPNET accounts:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetch12.asp

But get the error: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection

From what I read in the document it should try and connect with the ASPNET Process identity.

I have tested with Impersonation using a local windows account and UserID and Password in the connection string and can connect to the SQL server through the firewall so the relevant ports etc are open.

However I don't want to have user Id's and passwords in the connection string and would like to use integrated security.

Pls help as I am tearing all my hair out!!!!!This must be frustrating for you.

Could you post the connection string that is failing and maybe that will spark the answer?

Terri|||Thanks for your reply, however I organised a contractor to come in and check it out and when I showed him what the problem was it didn't happen and everything worked ok!!

Arrrggghhh!!! And nothing at all has/was changed.

Typical...

Cheers|||I have the EXACT same problem, only mine isn't fixing itself! I used the mirrored local ASPNET account and I am getting the login failed for user '(null)' message.

Connection string is: Data Source=<server name>;Initial Catalog=<database name>;Integrated Security=SSPI;

Any ideas?|||I spent hours upon hours trying to fix it.
Have you changed the 'machine' password in machine.config to match your local ASPNET Account?

Basically I changed that and set up the accounts and I got the error you are talking about, it came right by itself, when I think back it is possible I did a reboot of the webserver.|||You were right, I just needed to reboot the webserver. I guess the thing to remember is always reboot when you change machine.cofig.

Thanks, Cove!|||No problem. Probably stopping and starting the relevant services would have done the trick too??