A different question about SQL Server Access Denied

I have 2 development servers, both of which I need to use to run an ASP.NET app. The app connects to an external SQL Server with SQL Server authentication only. One of my servers connects properly, but the same exact app running on the second server generates the dreaded SQL Server Access Denied message. A traditional .asp file running on the second server does connect successfully to the database, so I have deduced that the problem is related either to the ASPNET account on the second server, or else to the structure of the server itself or IIS.

I have verified on both machines that IIS uses the ASPNET account for anonymous access. The only difference I can find is that the working server is using NTFS (and the VS_Developers account has full permission on my application's directory), while the problem server is using FAT. Does anyone know if it the FAT file system could be my problem? If so, should I convert to NTFS, or is there another solution? What else could I look at on the problem server? Any help would be greatly appreciated. Thanks.If you are using SQL Server authentication then using IIS anonymous accounts and ASP.Net accounts are not involved in the authentication. What is the exact message that appears? Login failed for user [...] ?

If you are using SQL server with SQL server authentication then in the connection string you should be providing the UID and Password of a SQL Server Login and there should be no "integrated security" clause in the connection string.|||Thanks for the reply. The error message is: "SQL Server does not exist or access is denied". There is no login failure error occurring.

Here is my connection string:
"Data Source=mySQLIPhere,1433;Network Library=DBMSSOCN;Initial Catalog=myDBName;User ID=mySQLUser;Password=mySQLPw;"

As I mentioned, this connection string works fine from one of the 2 development servers as well as from the production web server, so I don't think the connection string is the problem.|||Seems ok to me; if you are willing to do some experiments try these in order.

Verify that you can access mySQLIPhere machine from the machine causing the problem. e.g. by trying to open \\mySQLIPhere or by pinging.

Use query analyzer to connect to SQL Server from the machine causing problem. In "connect to SQL Server" dialog box provide mySQLIPhere as Sql Server name, select Sql Sever Auth, loginname and password. If this works you may experiment rewriting your connection string bit by bit e.g.:
"Data Source=mySQLIPhere; User ID=mySQLUser; Password=mySQLPw;"
"Data Source=mySQLIPhere,1433; User ID=mySQLUser; Password=mySQLPw;"
"Data Source=mySQLIPhere;Initial Catalog=myDBName; User ID=mySQLUser; Password=mySQLPw;"

It is most probably the SQL Server not exist (not found) part that looks true, rather than the access denied part.

4 CPU's on app server, can I buy only 1 license?

On a the db server, you can configure the db engine to only use 1 CPU
and therefore only have to purchase 1 SQL Server license. But on my app
server that has 4 CPU's, can I configure RS 2000 to only take advantage
of 1 of those CPU's and therefore only have to purchase 1 license for
the app server? How do I configure this on the app server side?On Jan 17, 1:21 pm, "Dave" <macleary2...@.yahoo.com> wrote:
> On a the db server, you can configure the db engine to only use 1 CPU
> and therefore only have to purchase 1 SQL Server license. But on my app
> server that has 4 CPU's, can I configure RS 2000 to only take advantage
> of 1 of those CPU's and therefore only have to purchase 1 license for
> the app server? How do I configure this on the app server side?
bumped. Anyone have an answer to this? Also, can this be done in RS
2005 and/or RS 2000? Or neither? Thanks.|||Hello,
If you have licensing per processor on application server you have to
purchase licenses
for all processors that are used by operating system on this server.
Microsoft says:
"Per-processor licensing. Required for extranet or Internet deployments.
Requires a single license for each CPU in the operating system instance
running Reporting Services. "
You can't set Reporting Services to use only one processor and purchase only
one per-processor license whereas operating systems uses all 4 processors.
In this situation Reporting Services might use only one CPU directly but
indirectly might use all 4 processors.
So that licenses for all processors are required.
Best Regards,
Radoslaw Lebkowski
Uzytkownik "Dave" <macleary2000@.yahoo.com> napisal w wiadomosci
news:1170951737.216688.228680@.m58g2000cwm.googlegroups.com...
> On Jan 17, 1:21 pm, "Dave" <macleary2...@.yahoo.com> wrote:
>> On a the db server, you can configure the db engine to only use 1 CPU
>> and therefore only have to purchase 1 SQL Server license. But on my app
>> server that has 4 CPU's, can I configure RS 2000 to only take advantage
>> of 1 of those CPU's and therefore only have to purchase 1 license for
>> the app server? How do I configure this on the app server side?
> bumped. Anyone have an answer to this? Also, can this be done in RS
> 2005 and/or RS 2000? Or neither? Thanks.
>

3rd party app supported on 32-bit sql, but not 64-bit?

Hi,

We have a 3rd party application which supports its DB running on SQL 2005.

Its a standard client/server windows application - very good, stable app.

They have told us that they only support it when it is running on 32-bit version of SQL 2005. Not 64-bit.

Is that common? Is that sensible?

Are there any differences on the DB Engine between 32-bit and 64-bit which would force them into that position?

Thanks,

Daniel.

There is no external difference between a 64bit and a 32bit SQL server. Unless they are installing something, like the app, on the server itself just tell them it is 32bit.

|||Actually unless their code is compiled with the AnyCPU build option you could run into issues related to installing a 32bits application in a 64bits box. In Win2003 server you have to run the code in WOW64 which is running it in 32bits mode but that will not resolve issues that require the AnyCPU build option. The main issue is that the application layer may not run without needed modifications. I am a beta 1 volunteer of the SQL Server 64bits project. Post again if you still have questions.