can not connect to remote SQL Express 2005

Hi,
I am having problems with my Visual Studio 2005 VB.net win app connecting
to SQL Express. I have configured my SQL Express to enable remote
connections, I believe it is correct, since others in the office can connect
to it using MS SQL Server Management Studio, and I can make a successful test
ODBC connection from the client computer, using both named pipes and tcpip.
But my VB.net app can not connect on the client computer, I get error -
System.Data.SqlClient.SqlException: An error has occurred while establishing
a connection to the server. When connecting to SQL Server 2005, this failure
may be caused by the fact that under the default settings SQL Server does not
allow remote connections. (provider: Named Pipes Provider, error: 40 - Could
not open a connection to SQL Server).
This app runs fine on the machine the SQL Express is running on (Windows
2000). My connection code is: Data Source=xxx\sqlexpress;Initial
Catalog=xxx;User ID=xxx;Password=xxx. I have tried putting np: and tcp: with
the port on the data source, but then the code doesn't run on the app on the
server...
Anybody know what I am doing wrong?
Thank you for any help.
Sandy
Hi,
any blocking firewall in the machine ? See if you can open up a
connction using the SQLCMD application from the command prompt.
HTH, Jens K. Suessmeyer.
http://www.sqlserver2005.de
|||Hi, Yes I can open a connection using SQLCMD, specifying both tcp with port,
and specifying np. The client machine doesn't have SQL installed, but the
odbc connections worked.
Sandy
"Jens" wrote:

> Hi,
> any blocking firewall in the machine ? See if you can open up a
> connction using the SQLCMD application from the command prompt.
> HTH, Jens K. Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
>

can not connect to remote SQL Express 2005

Hi,
I am having problems with my Visual Studio 2005 VB.net win app connecting
to SQL Express. I have configured my SQL Express to enable remote
connections, I believe it is correct, since others in the office can connec
t
to it using MS SQL Server Management Studio, and I can make a successful tes
t
ODBC connection from the client computer, using both named pipes and tcpip.
But my VB.net app can not connect on the client computer, I get error -
System.Data.SqlClient.SqlException: An error has occurred while establishing
a connection to the server. When connecting to SQL Server 2005, this failur
e
may be caused by the fact that under the default settings SQL Server does no
t
allow remote connections. (provider: Named Pipes Provider, error: 40 - Could
not open a connection to SQL Server).
This app runs fine on the machine the SQL Express is running on (Windows
2000). My connection code is: Data Source=xxx\sqlexpress;Initial
Catalog=xxx;User ID=xxx;Password=xxx. I have tried putting np: and tcp: wit
h
the port on the data source, but then the code doesn't run on the app on the
server...
Anybody know what I am doing wrong?
Thank you for any help.
SandyHi,
any blocking firewall in the machine ? See if you can open up a
connction using the SQLCMD application from the command prompt.
HTH, Jens K. Suessmeyer.
http://www.sqlserver2005.de
--|||Hi, Yes I can open a connection using SQLCMD, specifying both tcp with port
,
and specifying np. The client machine doesn't have SQL installed, but the
odbc connections worked.
Sandy
"Jens" wrote:

> Hi,
> any blocking firewall in the machine ? See if you can open up a
> connction using the SQLCMD application from the command prompt.
> HTH, Jens K. Suessmeyer.
> --
> http://www.sqlserver2005.de
> --
>

Can not connect to MS SQL server

Hi I have problems with connecting to MS SQL server.

SQL server is configured to log in with Windows Authentication mode.

The only thing I need is to configure the web.config.

My configuration in web.config-file is as follow:

<appSettings>

<addkey="forumDSN"value="server=localhost;uid=;pwd=;database=forum"/>

</appSettings>

I get the following message afte running my ASP page:

Exception Details:System.Data.SqlClient.SqlException: SQL Server does not exist or access denied.

HELP please.

Is the SQL Server on the same machine as the Web server? In the real Web.Config, to you provide an actual uid and password?|||

Hey hi,

1st u check out wheter the sql server whichs running has got any name...coz, some times the local host is not taken as the default instead, its named with some name.

to check that, just open the sql server service manager, there u can C Server :"........"

that name should be used.

also for further details go through the following link

http://www.functionx.com/sqlserver/Lesson01.htm

also the this one for the security issues

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

hope this helps

all the best

|||

yes, It is in the same machine running WindowsXP

thanks

sql

Can I use SQL Server security with reporting services?

I'm using SQL Server 2000 SP3 Reporting Services SP2
Currently my reports are configured to use a shared data source reference.
The credentials for the data source are configured to use the same specified
user name and password, which is a login I created for the purpose of
generating the reports.
Is there a way to pass a SQL Server account user name and password to the
data source instead of using a shared account?
I've tried creating a Data Source Credentials object, but it didn't work:
dim dsc as new DataSourceCredentials
dsc.DataSourceName = "dsn"
dsc.UserName = "unm"
dsc.Password = "pwd"
...
result = rs.Render (...,dsc,...)
...
Unfortunately, I am prevented from using integrated security.
The report renders fine using the data source reference pre-configured with
the shared username and password.
Thanks!
BillHere is what I do and I think is the best thing to do. Create a readonly SQL
Server user account. Use that for your shared datasource. Limit your access
to reports using the built in security model (based on roles). If a user has
rights to run the report they they see the data. They don't need to use
their SQL Server login to do so. This will prevent you from having to manage
SQL Server accounts as much. And, it is better for performance.
By using a single, read only account it means that all database access is
happening through that account which allows connection pooling to do its
magic. Connection pooling only works if the connection string is identical.
Establishing connections is expensive. If you go the route you are
suggesting (which is not possible out of the box, you would have to write
your own forms based authentication and integrate it) then every time a new
user requests a report there will be a new connection being established to
the server.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"BillE" <belgie@.datamti.com> wrote in message
news:ercHCCmCHHA.3924@.TK2MSFTNGP02.phx.gbl...
> I'm using SQL Server 2000 SP3 Reporting Services SP2
> Currently my reports are configured to use a shared data source reference.
> The credentials for the data source are configured to use the same
> specified user name and password, which is a login I created for the
> purpose of generating the reports.
> Is there a way to pass a SQL Server account user name and password to the
> data source instead of using a shared account?
> I've tried creating a Data Source Credentials object, but it didn't work:
> dim dsc as new DataSourceCredentials
> dsc.DataSourceName = "dsn"
> dsc.UserName = "unm"
> dsc.Password = "pwd"
> ...
> result = rs.Render (...,dsc,...)
> ...
> Unfortunately, I am prevented from using integrated security.
> The report renders fine using the data source reference pre-configured
> with the shared username and password.
> Thanks!
> Bill
>
>|||Thanks for your response. This is a grey area for me, and I'm having some
trouble with it.
In the model I'm using, the user selects parameters in a web forms
interface, which builds a URL and submits it to the report server. The
report is rendered in the browser.
If the user bookmarks the report, it can be retrieved at any time from the
report server by opening the bookmark. No login is necessary, since the
report uses the shared login.
I don't see a security context to prevent a user without the appropriate
role membership from accessing a report. Perhaps my entire model is flawed.
Thanks
Bill
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:OhCo0bmCHHA.4892@.TK2MSFTNGP04.phx.gbl...
> Here is what I do and I think is the best thing to do. Create a readonly
> SQL Server user account. Use that for your shared datasource. Limit your
> access to reports using the built in security model (based on roles). If a
> user has rights to run the report they they see the data. They don't need
> to use their SQL Server login to do so. This will prevent you from having
> to manage SQL Server accounts as much. And, it is better for performance.
> By using a single, read only account it means that all database access is
> happening through that account which allows connection pooling to do its
> magic. Connection pooling only works if the connection string is
> identical. Establishing connections is expensive. If you go the route you
> are suggesting (which is not possible out of the box, you would have to
> write your own forms based authentication and integrate it) then every
> time a new user requests a report there will be a new connection being
> established to the server.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
>
> "BillE" <belgie@.datamti.com> wrote in message
> news:ercHCCmCHHA.3924@.TK2MSFTNGP02.phx.gbl...
>> I'm using SQL Server 2000 SP3 Reporting Services SP2
>> Currently my reports are configured to use a shared data source
>> reference.
>> The credentials for the data source are configured to use the same
>> specified user name and password, which is a login I created for the
>> purpose of generating the reports.
>> Is there a way to pass a SQL Server account user name and password to the
>> data source instead of using a shared account?
>> I've tried creating a Data Source Credentials object, but it didn't work:
>> dim dsc as new DataSourceCredentials
>> dsc.DataSourceName = "dsn"
>> dsc.UserName = "unm"
>> dsc.Password = "pwd"
>> ...
>> result = rs.Render (...,dsc,...)
>> ...
>> Unfortunately, I am prevented from using integrated security.
>> The report renders fine using the data source reference pre-configured
>> with the shared username and password.
>> Thanks!
>> Bill
>>
>|||RS always has a security context. Being able to have a report rendered is
different from the security used to actually get the data. For the report to
be rendered RS has to know who the user is. It then uses its role based
security to decide whether to provide the service. Then it renders the
report using the security specified for getting the data. Two levels of
security. Rights to run/render the report, rights to get the data. You have
been thinking on the latter when really the issue is more the former.
You have three choices.
1. Create your own authentication. This allows you to have the user log to
your app using the SQL Server login and have that be the login to your app.
You have to integrate this into Reporting Services.
2. Use integrated security where the windows credentials are used to
authenticate into RS. Then integrated security is use for the data source of
the reports as well.
3. Use integrated security where the windows credentials are used to
authenticate into RS. Then, use a fixed SQL Server account (one or more) in
the credentials tab of shared data source.
I do and recommend #3. #1 is non-trivial. #2 is lower performing and in your
case you say you can't use.
--
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"BillE" <belgie@.datamti.com> wrote in message
news:uEuGchnCHHA.3228@.TK2MSFTNGP03.phx.gbl...
> Thanks for your response. This is a grey area for me, and I'm having some
> trouble with it.
> In the model I'm using, the user selects parameters in a web forms
> interface, which builds a URL and submits it to the report server. The
> report is rendered in the browser.
> If the user bookmarks the report, it can be retrieved at any time from the
> report server by opening the bookmark. No login is necessary, since the
> report uses the shared login.
> I don't see a security context to prevent a user without the appropriate
> role membership from accessing a report. Perhaps my entire model is
> flawed.
> Thanks
> Bill
>
> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> news:OhCo0bmCHHA.4892@.TK2MSFTNGP04.phx.gbl...
>> Here is what I do and I think is the best thing to do. Create a readonly
>> SQL Server user account. Use that for your shared datasource. Limit your
>> access to reports using the built in security model (based on roles). If
>> a user has rights to run the report they they see the data. They don't
>> need to use their SQL Server login to do so. This will prevent you from
>> having to manage SQL Server accounts as much. And, it is better for
>> performance.
>> By using a single, read only account it means that all database access is
>> happening through that account which allows connection pooling to do its
>> magic. Connection pooling only works if the connection string is
>> identical. Establishing connections is expensive. If you go the route you
>> are suggesting (which is not possible out of the box, you would have to
>> write your own forms based authentication and integrate it) then every
>> time a new user requests a report there will be a new connection being
>> established to the server.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>>
>> "BillE" <belgie@.datamti.com> wrote in message
>> news:ercHCCmCHHA.3924@.TK2MSFTNGP02.phx.gbl...
>> I'm using SQL Server 2000 SP3 Reporting Services SP2
>> Currently my reports are configured to use a shared data source
>> reference.
>> The credentials for the data source are configured to use the same
>> specified user name and password, which is a login I created for the
>> purpose of generating the reports.
>> Is there a way to pass a SQL Server account user name and password to
>> the data source instead of using a shared account?
>> I've tried creating a Data Source Credentials object, but it didn't
>> work:
>> dim dsc as new DataSourceCredentials
>> dsc.DataSourceName = "dsn"
>> dsc.UserName = "unm"
>> dsc.Password = "pwd"
>> ...
>> result = rs.Render (...,dsc,...)
>> ...
>> Unfortunately, I am prevented from using integrated security.
>> The report renders fine using the data source reference pre-configured
>> with the shared username and password.
>> Thanks!
>> Bill
>>
>>
>|||This client has users sharing computers, and they don't want to log off and
log on each time they switch users. However, one user may have access to
some reports which another user doesn't.
I'll have to pursue option #1, or (preferably) convince the client to come
to his senses.
Thanks for your help, I have a clearer understanding of the situation now.
Bill
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%232RmlDoCHHA.4256@.TK2MSFTNGP04.phx.gbl...
> RS always has a security context. Being able to have a report rendered is
> different from the security used to actually get the data. For the report
> to be rendered RS has to know who the user is. It then uses its role based
> security to decide whether to provide the service. Then it renders the
> report using the security specified for getting the data. Two levels of
> security. Rights to run/render the report, rights to get the data. You
> have been thinking on the latter when really the issue is more the former.
> You have three choices.
> 1. Create your own authentication. This allows you to have the user log to
> your app using the SQL Server login and have that be the login to your
> app. You have to integrate this into Reporting Services.
> 2. Use integrated security where the windows credentials are used to
> authenticate into RS. Then integrated security is use for the data source
> of the reports as well.
> 3. Use integrated security where the windows credentials are used to
> authenticate into RS. Then, use a fixed SQL Server account (one or more)
> in the credentials tab of shared data source.
> I do and recommend #3. #1 is non-trivial. #2 is lower performing and in
> your case you say you can't use.
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "BillE" <belgie@.datamti.com> wrote in message
> news:uEuGchnCHHA.3228@.TK2MSFTNGP03.phx.gbl...
>> Thanks for your response. This is a grey area for me, and I'm having
>> some trouble with it.
>> In the model I'm using, the user selects parameters in a web forms
>> interface, which builds a URL and submits it to the report server. The
>> report is rendered in the browser.
>> If the user bookmarks the report, it can be retrieved at any time from
>> the report server by opening the bookmark. No login is necessary, since
>> the report uses the shared login.
>> I don't see a security context to prevent a user without the appropriate
>> role membership from accessing a report. Perhaps my entire model is
>> flawed.
>> Thanks
>> Bill
>>
>> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
>> news:OhCo0bmCHHA.4892@.TK2MSFTNGP04.phx.gbl...
>> Here is what I do and I think is the best thing to do. Create a readonly
>> SQL Server user account. Use that for your shared datasource. Limit your
>> access to reports using the built in security model (based on roles). If
>> a user has rights to run the report they they see the data. They don't
>> need to use their SQL Server login to do so. This will prevent you from
>> having to manage SQL Server accounts as much. And, it is better for
>> performance.
>> By using a single, read only account it means that all database access
>> is happening through that account which allows connection pooling to do
>> its magic. Connection pooling only works if the connection string is
>> identical. Establishing connections is expensive. If you go the route
>> you are suggesting (which is not possible out of the box, you would have
>> to write your own forms based authentication and integrate it) then
>> every time a new user requests a report there will be a new connection
>> being established to the server.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>>
>> "BillE" <belgie@.datamti.com> wrote in message
>> news:ercHCCmCHHA.3924@.TK2MSFTNGP02.phx.gbl...
>> I'm using SQL Server 2000 SP3 Reporting Services SP2
>> Currently my reports are configured to use a shared data source
>> reference.
>> The credentials for the data source are configured to use the same
>> specified user name and password, which is a login I created for the
>> purpose of generating the reports.
>> Is there a way to pass a SQL Server account user name and password to
>> the data source instead of using a shared account?
>> I've tried creating a Data Source Credentials object, but it didn't
>> work:
>> dim dsc as new DataSourceCredentials
>> dsc.DataSourceName = "dsn"
>> dsc.UserName = "unm"
>> dsc.Password = "pwd"
>> ...
>> result = rs.Render (...,dsc,...)
>> ...
>> Unfortunately, I am prevented from using integrated security.
>> The report renders fine using the data source reference pre-configured
>> with the shared username and password.
>> Thanks!
>> Bill
>>
>>
>>
>

Can I use a stored procedure for INSERT in SqlDataSource?

Hello,

I have created a web page with a FormView that allows me to add and edit data in my database. I configured the SqlDataSource control and it populated the SELECT, INSERT, UPDATE and DELETE statements. I've created a stored procedure to do the INSERT and return to new identity value. My question is this: Can I configure the control to use this stored procedure? If so, how? Or do I have to write some code for one of the event handlers (inserting, updating?)

Any help would be appreciated.

-brian

Yes you can. Not seeing your code makes it difficult to diagnose, but it sounds like you have the SqlDataSource partially set up. Make sure you also have the insertcommand attribute set to your new stored procedure and the insertcommandtype set to "StoredProcedure". The InsertParameters should also be set to include any input parameters that are not explicitly bound within the FormView.InsertItemTemplate.

From here, you need to make sure the FormView is in insert mode, your InsertItemTemplate is properly set up, and you have an insert button with the CommandName attribute properly set to "Insert".

Once you click that button, the FormView.ItemInserting event will fire, then the SqlDataSource.Inserting event will fire.

Assuming you have all of your stored procedure input parameters properly set up within your ASPX page, your stored procedure should run, and you can pick up your return parameter from the SqlDataSource.Inserted event.

Hope this helps.