bulk insert

We have an clustered sql server 2000 with service pack 4. We are trying to
import some date using 'bulk insert'. The command ends ok but there is no
rows inserted on our table. Furthermore if we specifify a data_file that not
exists the commands end ok with no error message.
The same command and same data_file in our development environment (sql
server 2000 service pack 4 NOT clustered) works fine and if we specify a data
file that not exists we receive the corresponding error message.
That doesn't sond right. We do bulk insert into clustered SQL instances all
the time, and if a non-existing file is specified, an error stating 'file
does not exist' is encountered.
It may help if you post you BULK INSERT statement. Something is missing here.
Linchi
"Juan Bautista" wrote:

> We have an clustered sql server 2000 with service pack 4. We are trying to
> import some date using 'bulk insert'. The command ends ok but there is no
> rows inserted on our table. Furthermore if we specifify a data_file that not
> exists the commands end ok with no error message.
> The same command and same data_file in our development environment (sql
> server 2000 service pack 4 NOT clustered) works fine and if we specify a data
> file that not exists we receive the corresponding error message.
|||Thanks for your reply, here is the bulk insert statement, as you could
see there is nothing special in it.
BULK INSERT Users_Table
FROM 'F:\UsersLoad.txt'
WITH (
fieldterminator='|'
rowterminator='\n' )
"Linchi Shea" wrote:
[vbcol=seagreen]
> That doesn't sond right. We do bulk insert into clustered SQL instances all
> the time, and if a non-existing file is specified, an error stating 'file
> does not exist' is encountered.
> It may help if you post you BULK INSERT statement. Something is missing here.
> Linchi
> "Juan Bautista" wrote:
|||Is the F: drive local for each cluster node, or is it a shared cluster
physical drive resource?
Anthony Thomas

"Juan Bautista" <JuanBautista@.discussions.microsoft.com> wrote in message
news:CA335F4E-A9C6-4117-A107-53CD1995B21F@.microsoft.com...[vbcol=seagreen]
> Thanks for your reply, here is the bulk insert statement, as you could
> see there is nothing special in it.
> BULK INSERT Users_Table
> FROM 'F:\UsersLoad.txt'
> WITH (
> fieldterminator='|'
> rowterminator='\n' )
> "Linchi Shea" wrote:
all[vbcol=seagreen]
'file[vbcol=seagreen]
here.[vbcol=seagreen]
trying to[vbcol=seagreen]
no[vbcol=seagreen]
that not[vbcol=seagreen]
(sql[vbcol=seagreen]
a data[vbcol=seagreen]
|||The drive F: is a shared cluster physical drive resource.
"Anthony Thomas" wrote:

> Is the F: drive local for each cluster node, or is it a shared cluster
> physical drive resource?
>
> Anthony Thomas
>
> --
> "Juan Bautista" <JuanBautista@.discussions.microsoft.com> wrote in message
> news:CA335F4E-A9C6-4117-A107-53CD1995B21F@.microsoft.com...
> all
> 'file
> here.
> trying to
> no
> that not
> (sql
> a data
>
>

BUILTIN\Administrators

Hi,
I must remove BUILTIN\Administrators. Should i create 2 domain accounts, one for each service (MSSQLServer, SQL Server Agent) or one for the two services ' actually i'm using LOCAL SYSTEM ACCOUNT.
If i use 2 accounts i must give sysadmin for the two accounts, and i don't use the account sa, i have one other account with sysadmin permiss=F5es for my day by day work. When i use MBSA, i always get the message that i have more than 2 sysadmins. How can i troubleshoot this question '
What is your approach of remove BUILTIN\Administrators and start the accounts with domain non admin accounts ?
My approach:
-Remove BUILTIN\Administrators
-create one domain account with regular priviledges
-assign the account for the two services
-grant SQLServer sysadmin rights on the account
Can anyone give a nice approach for this question ? issues regarding the change ?
Thanks in advance for the help
Miguel
MCPI would use 1 domain account... The necessary permissions can be found in
books on line. Search for "service accounts"
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Miguel" <anonymous@.discussions.microsoft.com> wrote in message
news:05fc01c3db7f$f6c96870$a001280a@.phx.gbl...
Hi,
I must remove BUILTIN\Administrators. Should i create 2
domain accounts, one for each service (MSSQLServer, SQL
Server Agent) or one for the two services ' actually i'm
using LOCAL SYSTEM ACCOUNT.
If i use 2 accounts i must give sysadmin for the two
accounts, and i don't use the account sa, i have one other
account with sysadmin permissões for my day by day work.
When i use MBSA, i always get the message that i have more
than 2 sysadmins. How can i troubleshoot this question '
What is your approach of remove BUILTIN\Administrators and
start the accounts with domain non admin accounts ?
My approach:
-Remove BUILTIN\Administrators
-create one domain account with regular priviledges
-assign the account for the two services
-grant SQLServer sysadmin rights on the account
Can anyone give a nice approach for this question ?
issues regarding the change ?
Thanks in advance for the help
Miguel
MCP

BUILTIN\Administrators

Hi,
I must remove BUILTIN\Administrators. Should i create 2=20
domain accounts, one for each service (MSSQLServer, SQL=20
Server Agent) or one for the two services ' actually i'm=20
using LOCAL SYSTEM ACCOUNT.
If i use 2 accounts i must give sysadmin for the two=20
accounts, and i don't use the account sa, i have one other=20
account with sysadmin permiss=F5es for my day by day work.=20
When i use MBSA, i always get the message that i have more=20
than 2 sysadmins. How can i troubleshoot this question '
What is your approach of remove BUILTIN\Administrators and=20
start the accounts with domain non admin accounts ?
My approach:
-Remove BUILTIN\Administrators
-create one domain account with regular priviledges
-assign the account for the two services
-grant SQLServer sysadmin rights on the account
Can anyone give a nice approach for this question ?=20
issues regarding the change ?
Thanks in advance for the help
Miguel
MCPI would use 1 domain account... The necessary permissions can be found in
books on line. Search for "service accounts"
Wayne Snyder, MCDBA, SQL Server MVP
Computer Education Services Corporation (CESC), Charlotte, NC
www.computeredservices.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Miguel" <anonymous@.discussions.microsoft.com> wrote in message
news:05fc01c3db7f$f6c96870$a001280a@.phx.gbl...
Hi,
I must remove BUILTIN\Administrators. Should i create 2
domain accounts, one for each service (MSSQLServer, SQL
Server Agent) or one for the two services ' actually i'm
using LOCAL SYSTEM ACCOUNT.
If i use 2 accounts i must give sysadmin for the two
accounts, and i don't use the account sa, i have one other
account with sysadmin permisses for my day by day work.
When i use MBSA, i always get the message that i have more
than 2 sysadmins. How can i troubleshoot this question '
What is your approach of remove BUILTIN\Administrators and
start the accounts with domain non admin accounts ?
My approach:
-Remove BUILTIN\Administrators
-create one domain account with regular priviledges
-assign the account for the two services
-grant SQLServer sysadmin rights on the account
Can anyone give a nice approach for this question ?
issues regarding the change ?
Thanks in advance for the help
Miguel
MCP

builtin/administrators

Hi, our sql box has too many people (including sql service account) with
local admin rights, some even have domain admin rights. I am trying to
tighten the security on those boxes and decrease the security level of those
people. What I am planning to do is take builtin/administrator login out of
the sql box, and add sql services account back and grant SA rights to it.
Does anyone see any problem with this approach? Thanks.
I suggest you start with creating a new windows group, ad appropriate windows users, add it to SQL
Server and grant sysadmin for that. Unless you already have such, of course. :-)
One thing I know can be a problem is full-text search. I think that "local system" is granted login
to SQL server through builtin\Administrators, and hereby lies the problem. That should be OK by
adding "NT Authority" (or whatever the physical name for LocalSystem is). I suggest you Google the
archives for a bit more info on that.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"flologic" <flo@.flo.net> wrote in message news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...
> Hi, our sql box has too many people (including sql service account) with
> local admin rights, some even have domain admin rights. I am trying to
> tighten the security on those boxes and decrease the security level of those
> people. What I am planning to do is take builtin/administrator login out of
> the sql box, and add sql services account back and grant SA rights to it.
> Does anyone see any problem with this approach? Thanks.
>
|||flo,
Here is an article (talking about clusters) that addresses some of your
concerns.
http://support.microsoft.com/default...b;en-us;263712
One example of a side-effect that you must manage is:
http://support.microsoft.com/default...b;en-us;237604
Also, from the BOL on: Setting up Windows Services Accounts
If the startup account assigned to the MSSQLServer Service is not a member
of the Local Administrators group, or if the BUILTIN\Administrators SQL
Server login has been removed, you must add the startup account for the
MSSQLServer service or the SQLServerAgent service, or both, to the SQL
Server system administrators (sysadmin) role. Grant the [Domain\NTaccount]
user a logon to SQL Server.
Hope that helps you.
Russell Fields
"flologic" <flo@.flo.net> wrote in message
news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...
> Hi, our sql box has too many people (including sql service account) with
> local admin rights, some even have domain admin rights. I am trying to
> tighten the security on those boxes and decrease the security level of
those
> people. What I am planning to do is take builtin/administrator login out
of
> the sql box, and add sql services account back and grant SA rights to it.
> Does anyone see any problem with this approach? Thanks.
>
|||The account for local system is NT Authority\SYSTEM.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||If you add ANY NT group and grant that group SQL Admin privileges then you
can NOT prevent the NT admins from coming in... All they have to do is add
themselves to the NT group;...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Russell Fields" <RussellFields@.NoMailPlease.Com> wrote in message
news:Of5AOPGhEHA.1356@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> flo,
> Here is an article (talking about clusters) that addresses some of your
> concerns.
> http://support.microsoft.com/default...b;en-us;263712
> One example of a side-effect that you must manage is:
> http://support.microsoft.com/default...b;en-us;237604
> Also, from the BOL on: Setting up Windows Services Accounts
> If the startup account assigned to the MSSQLServer Service is not a member
> of the Local Administrators group, or if the BUILTIN\Administrators SQL
> Server login has been removed, you must add the startup account for the
> MSSQLServer service or the SQLServerAgent service, or both, to the SQL
> Server system administrators (sysadmin) role. Grant the [Domain\NTaccount]
> user a logon to SQL Server.
> Hope that helps you.
> Russell Fields
> "flologic" <flo@.flo.net> wrote in message
> news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...
> those
> of
it.
>

builtin/administrators

Hi, our sql box has too many people (including sql service account) with
local admin rights, some even have domain admin rights. I am trying to
tighten the security on those boxes and decrease the security level of those
people. What I am planning to do is take builtin/administrator login out of
the sql box, and add sql services account back and grant SA rights to it.
Does anyone see any problem with this approach? Thanks.I suggest you start with creating a new windows group, ad appropriate windows users, add it to SQL
Server and grant sysadmin for that. Unless you already have such, of course. :-)
One thing I know can be a problem is full-text search. I think that "local system" is granted login
to SQL server through builtin\Administrators, and hereby lies the problem. That should be OK by
adding "NT Authority" (or whatever the physical name for LocalSystem is). I suggest you Google the
archives for a bit more info on that.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"flologic" <flo@.flo.net> wrote in message news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...
> Hi, our sql box has too many people (including sql service account) with
> local admin rights, some even have domain admin rights. I am trying to
> tighten the security on those boxes and decrease the security level of those
> people. What I am planning to do is take builtin/administrator login out of
> the sql box, and add sql services account back and grant SA rights to it.
> Does anyone see any problem with this approach? Thanks.
>|||flo,
Here is an article (talking about clusters) that addresses some of your
concerns.
http://support.microsoft.com/default.aspx?scid=kb;en-us;263712
One example of a side-effect that you must manage is:
http://support.microsoft.com/default.aspx?scid=kb;en-us;237604
Also, from the BOL on: Setting up Windows Services Accounts
If the startup account assigned to the MSSQLServer Service is not a member
of the Local Administrators group, or if the BUILTIN\Administrators SQL
Server login has been removed, you must add the startup account for the
MSSQLServer service or the SQLServerAgent service, or both, to the SQL
Server system administrators (sysadmin) role. Grant the [Domain\NTaccount]
user a logon to SQL Server.
Hope that helps you.
Russell Fields
"flologic" <flo@.flo.net> wrote in message
news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...
> Hi, our sql box has too many people (including sql service account) with
> local admin rights, some even have domain admin rights. I am trying to
> tighten the security on those boxes and decrease the security level of
those
> people. What I am planning to do is take builtin/administrator login out
of
> the sql box, and add sql services account back and grant SA rights to it.
> Does anyone see any problem with this approach? Thanks.
>|||The account for local system is NT Authority\SYSTEM.
Rand
This posting is provided "as is" with no warranties and confers no rights.|||If you add ANY NT group and grant that group SQL Admin privileges then you
can NOT prevent the NT admins from coming in... All they have to do is add
themselves to the NT group;...
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Russell Fields" <RussellFields@.NoMailPlease.Com> wrote in message
news:Of5AOPGhEHA.1356@.TK2MSFTNGP09.phx.gbl...
> flo,
> Here is an article (talking about clusters) that addresses some of your
> concerns.
> http://support.microsoft.com/default.aspx?scid=kb;en-us;263712
> One example of a side-effect that you must manage is:
> http://support.microsoft.com/default.aspx?scid=kb;en-us;237604
> Also, from the BOL on: Setting up Windows Services Accounts
> If the startup account assigned to the MSSQLServer Service is not a member
> of the Local Administrators group, or if the BUILTIN\Administrators SQL
> Server login has been removed, you must add the startup account for the
> MSSQLServer service or the SQLServerAgent service, or both, to the SQL
> Server system administrators (sysadmin) role. Grant the [Domain\NTaccount]
> user a logon to SQL Server.
> Hope that helps you.
> Russell Fields
> "flologic" <flo@.flo.net> wrote in message
> news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...
> > Hi, our sql box has too many people (including sql service account) with
> > local admin rights, some even have domain admin rights. I am trying to
> > tighten the security on those boxes and decrease the security level of
> those
> > people. What I am planning to do is take builtin/administrator login out
> of
> > the sql box, and add sql services account back and grant SA rights to
it.
> > Does anyone see any problem with this approach? Thanks.
> >
> >
>

builtin/administrators

Hi, our sql box has too many people (including sql service account) with
local admin rights, some even have domain admin rights. I am trying to
tighten the security on those boxes and decrease the security level of those
people. What I am planning to do is take builtin/administrator login out of
the sql box, and add sql services account back and grant SA rights to it.
Does anyone see any problem with this approach? Thanks.I suggest you start with creating a new windows group, ad appropriate window
s users, add it to SQL
Server and grant sysadmin for that. Unless you already have such, of course.
:-)
One thing I know can be a problem is full-text search. I think that "local s
ystem" is granted login
to SQL server through builtin\Administrators, and hereby lies the problem. T
hat should be OK by
adding "NT Authority" (or whatever the physical name for LocalSystem is). I
suggest you Google the
archives for a bit more info on that.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"flologic" <flo@.flo.net> wrote in message news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...[vbcol
=seagreen]
> Hi, our sql box has too many people (including sql service account) with
> local admin rights, some even have domain admin rights. I am trying to
> tighten the security on those boxes and decrease the security level of tho
se
> people. What I am planning to do is take builtin/administrator login out o
f
> the sql box, and add sql services account back and grant SA rights to it.
> Does anyone see any problem with this approach? Thanks.
>[/vbcol]|||flo,
Here is an article (talking about clusters) that addresses some of your
concerns.
http://support.microsoft.com/defaul...kb;en-us;263712
One example of a side-effect that you must manage is:
http://support.microsoft.com/defaul...kb;en-us;237604
Also, from the BOL on: Setting up Windows Services Accounts
If the startup account assigned to the MSSQLServer Service is not a member
of the Local Administrators group, or if the BUILTIN\Administrators SQL
Server login has been removed, you must add the startup account for the
MSSQLServer service or the SQLServerAgent service, or both, to the SQL
Server system administrators (sysadmin) role. Grant the [Domain\NTaccoun
t]
user a logon to SQL Server.
Hope that helps you.
Russell Fields
"flologic" <flo@.flo.net> wrote in message
news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...
> Hi, our sql box has too many people (including sql service account) with
> local admin rights, some even have domain admin rights. I am trying to
> tighten the security on those boxes and decrease the security level of
those
> people. What I am planning to do is take builtin/administrator login out
of
> the sql box, and add sql services account back and grant SA rights to it.
> Does anyone see any problem with this approach? Thanks.
>|||The account for local system is NT Authority\SYSTEM.
Rand
This posting is provided "as is" with no warranties and confers no rights.|||If you add ANY NT group and grant that group SQL Admin privileges then you
can NOT prevent the NT admins from coming in... All they have to do is add
themselves to the NT group;...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Russell Fields" <RussellFields@.NoMailPlease.Com> wrote in message
news:Of5AOPGhEHA.1356@.TK2MSFTNGP09.phx.gbl...
> flo,
> Here is an article (talking about clusters) that addresses some of your
> concerns.
> http://support.microsoft.com/defaul...kb;en-us;263712
> One example of a side-effect that you must manage is:
> http://support.microsoft.com/defaul...kb;en-us;237604
> Also, from the BOL on: Setting up Windows Services Accounts
> If the startup account assigned to the MSSQLServer Service is not a member
> of the Local Administrators group, or if the BUILTIN\Administrators SQL
> Server login has been removed, you must add the startup account for the
> MSSQLServer service or the SQLServerAgent service, or both, to the SQL
> Server system administrators (sysadmin) role. Grant the [Domain\NTacco
unt]
> user a logon to SQL Server.
> Hope that helps you.
> Russell Fields
> "flologic" <flo@.flo.net> wrote in message
> news:eReee6FhEHA.632@.TK2MSFTNGP12.phx.gbl...
> those
> of
it.[vbcol=seagreen]
>

Building a report on top of a basicHttpBinding WCF Service

Hello,

I'm currenlty stuck in a situation not unlike http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1910495&SiteID=1 .

I've built a service exposed as basicHTTPBinding with WCF and am trying to create a report using this service as a datasource.

I've used a ".svc" file to host my web service as part of an existing ASP.NET application.

In my dev environment, the service is accessible as ht tp://localhost:10827/IncidentListes.svc (which gives the "how to generate a client for this service" page) while ht tp://localhost:10827/IncidentListes.svc?wsdl returns the following WSDL for the service :

"

<?xml version="1.0" encoding="utf-8" ?>

- <wsdlefinitions name="IncidentSrv" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlnsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlnsoapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlnsoap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">

- <wsdl:types>

- <xsdchema targetNamespace="http://tempuri.org/Imports">

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd0" namespace="http://tempuri.org/" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd2" namespace="http://schemas.datacontract.org/2004/07/Sncf.Dsit.Carto.Domaine.IncidentsSecurite" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd3" namespace="http://schemas.datacontract.org/2004/07/Sncf.Dsit.Carto.Domaine" />

</xsdchema>

</wsdl:types>

- <wsdl:message name="IIncidentSrv_ListePourUtilisateur_InputMessage">

<wsdlart name="parameters" element="tns:ListePourUtilisateur" />

</wsdl:message>

- <wsdl:message name="IIncidentSrv_ListePourUtilisateur_OutputMessage">

<wsdlart name="parameters" element="tns:ListePourUtilisateurResponse" />

</wsdl:message>

- <wsdlortType name="IIncidentSrv">

- <wsdlperation name="ListePourUtilisateur">

<wsdl:input wsaw:Action="http://tempuri.org/IIncidentSrv/ListePourUtilisateur" message="tns:IIncidentSrv_ListePourUtilisateur_InputMessage" />

<wsdlutput wsaw:Action="http://tempuri.org/IIncidentSrv/ListePourUtilisateurResponse" message="tns:IIncidentSrv_ListePourUtilisateur_OutputMessage" />

</wsdlperation>

</wsdlortType>

- <wsdl:binding name="BasicHttpBinding_IIncidentSrv" type="tns:IIncidentSrv">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />

- <wsdlperation name="ListePourUtilisateur">

<soapperation soapAction="http://tempuri.org/IIncidentSrv/ListePourUtilisateur" style="document" />

- <wsdl:input>

<soap:body use="literal" />

</wsdl:input>

- <wsdlutput>

<soap:body use="literal" />

</wsdlutput>

</wsdlperation>

</wsdl:binding>

- <wsdlervice name="IncidentSrv">

- <wsdlort name="BasicHttpBinding_IIncidentSrv" binding="tns:BasicHttpBinding_IIncidentSrv">

<soap:address location="http://localhost:10827/IncidentListes.svc" />

</wsdlort>

</wsdlervice>

</wsdlefinitions>

"

1) Which URL should I use as the connection string in the dataset wizard ? With or without the "?wsdl" ?

2) How do I write the "<query>" block to obtain the results of the ListePourUtilisateur method as my dataset ?

Okay, this is solved now ... mainly after realizing that the "Cannot execute URL query" error dialog had a small "details" button that actually brought up some useful information.

The problem was actually a namespace incoherence between the WSDL and my <Query>. Once this was fixed, it worked like a charm.

|||

Hey Renaud,

Could you tell me what the exact problem was (what did you entered for Querystring), because we're having the same problem.

Thanks alot,

Jeroen.

|||

Hi Jeroen,

For the query string we simply use the URL of our ".svc" page.

For the query itself, we use the following style :

<Query>
<SoapAction>
http://Namespace/ServiceName </SoapAction>
<Method Namespace="http://Namespace"
Name="ServiceName">
<Parameters>

<Parameter Name="name">
</Parameter>

</Parameters>
</Method>
<ElementPath IgnoreNamespaces="true">MethodNameResponse{}/MethodNameResult{}/ObjectName{Fields}</ElementPath>
</Query>

Hope this helps,

Renaud

Building a report on top of a basicHttpBinding WCF Service

Hello,

I'm currenlty stuck in a situation not unlike http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1910495&SiteID=1 .

I've built a service exposed as basicHTTPBinding with WCF and am trying to create a report using this service as a datasource.

I've used a ".svc" file to host my web service as part of an existing ASP.NET application.

In my dev environment, the service is accessible as ht tp://localhost:10827/IncidentListes.svc (which gives the "how to generate a client for this service" page) while ht tp://localhost:10827/IncidentListes.svc?wsdl returns the following WSDL for the service :

"

<?xml version="1.0" encoding="utf-8" ?>

- <wsdlefinitions name="IncidentSrv" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlnsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlnsoapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlnsoap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">

- <wsdl:types>

- <xsdchema targetNamespace="http://tempuri.org/Imports">

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd0" namespace="http://tempuri.org/" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd2" namespace="http://schemas.datacontract.org/2004/07/Sncf.Dsit.Carto.Domaine.IncidentsSecurite" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd3" namespace="http://schemas.datacontract.org/2004/07/Sncf.Dsit.Carto.Domaine" />

</xsdchema>

</wsdl:types>

- <wsdl:message name="IIncidentSrv_ListePourUtilisateur_InputMessage">

<wsdlart name="parameters" element="tns:ListePourUtilisateur" />

</wsdl:message>

- <wsdl:message name="IIncidentSrv_ListePourUtilisateur_OutputMessage">

<wsdlart name="parameters" element="tns:ListePourUtilisateurResponse" />

</wsdl:message>

- <wsdlortType name="IIncidentSrv">

- <wsdlperation name="ListePourUtilisateur">

<wsdl:input wsaw:Action="http://tempuri.org/IIncidentSrv/ListePourUtilisateur" message="tns:IIncidentSrv_ListePourUtilisateur_InputMessage" />

<wsdlutput wsaw:Action="http://tempuri.org/IIncidentSrv/ListePourUtilisateurResponse" message="tns:IIncidentSrv_ListePourUtilisateur_OutputMessage" />

</wsdlperation>

</wsdlortType>

- <wsdl:binding name="BasicHttpBinding_IIncidentSrv" type="tns:IIncidentSrv">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />

- <wsdlperation name="ListePourUtilisateur">

<soapperation soapAction="http://tempuri.org/IIncidentSrv/ListePourUtilisateur" style="document" />

- <wsdl:input>

<soap:body use="literal" />

</wsdl:input>

- <wsdlutput>

<soap:body use="literal" />

</wsdlutput>

</wsdlperation>

</wsdl:binding>

- <wsdlervice name="IncidentSrv">

- <wsdlort name="BasicHttpBinding_IIncidentSrv" binding="tns:BasicHttpBinding_IIncidentSrv">

<soap:address location="http://localhost:10827/IncidentListes.svc" />

</wsdlort>

</wsdlervice>

</wsdlefinitions>

"

1) Which URL should I use as the connection string in the dataset wizard ? With or without the "?wsdl" ?

2) How do I write the "<query>" block to obtain the results of the ListePourUtilisateur method as my dataset ?

Okay, this is solved now ... mainly after realizing that the "Cannot execute URL query" error dialog had a small "details" button that actually brought up some useful information.

The problem was actually a namespace incoherence between the WSDL and my <Query>. Once this was fixed, it worked like a charm.

|||

Hey Renaud,

Could you tell me what the exact problem was (what did you entered for Querystring), because we're having the same problem.

Thanks alot,

Jeroen.

|||

Hi Jeroen,

For the query string we simply use the URL of our ".svc" page.

For the query itself, we use the following style :

<Query>
<SoapAction>
http://Namespace/ServiceName </SoapAction>
<Method Namespace="http://Namespace"
Name="ServiceName">
<Parameters>

<Parameter Name="name">
</Parameter>

</Parameters>
</Method>
<ElementPath IgnoreNamespaces="true">MethodNameResponse{}/MethodNameResult{}/ObjectName{Fields}</ElementPath>
</Query>

Hope this helps,

Renaud

Building a report on top of a basicHttpBinding WCF Service

Hello,

I'm currenlty stuck in a situation not unlike http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1910495&SiteID=1 .

I've built a service exposed as basicHTTPBinding with WCF and am trying to create a report using this service as a datasource.

I've used a ".svc" file to host my web service as part of an existing ASP.NET application.

In my dev environment, the service is accessible as ht tp://localhost:10827/IncidentListes.svc (which gives the "how to generate a client for this service" page) while ht tp://localhost:10827/IncidentListes.svc?wsdl returns the following WSDL for the service :

"

<?xml version="1.0" encoding="utf-8" ?>

- <wsdlefinitions name="IncidentSrv" targetNamespace="http://tempuri.org/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlnsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlnsoapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://tempuri.org/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlnsoap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex">

- <wsdl:types>

- <xsdchema targetNamespace="http://tempuri.org/Imports">

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd0" namespace="http://tempuri.org/" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd2" namespace="http://schemas.datacontract.org/2004/07/Sncf.Dsit.Carto.Domaine.IncidentsSecurite" />

<xsd:import schemaLocation="http://localhost:10827/IncidentListes.svc?xsd=xsd3" namespace="http://schemas.datacontract.org/2004/07/Sncf.Dsit.Carto.Domaine" />

</xsdchema>

</wsdl:types>

- <wsdl:message name="IIncidentSrv_ListePourUtilisateur_InputMessage">

<wsdlart name="parameters" element="tns:ListePourUtilisateur" />

</wsdl:message>

- <wsdl:message name="IIncidentSrv_ListePourUtilisateur_OutputMessage">

<wsdlart name="parameters" element="tns:ListePourUtilisateurResponse" />

</wsdl:message>

- <wsdlortType name="IIncidentSrv">

- <wsdlperation name="ListePourUtilisateur">

<wsdl:input wsaw:Action="http://tempuri.org/IIncidentSrv/ListePourUtilisateur" message="tns:IIncidentSrv_ListePourUtilisateur_InputMessage" />

<wsdlutput wsaw:Action="http://tempuri.org/IIncidentSrv/ListePourUtilisateurResponse" message="tns:IIncidentSrv_ListePourUtilisateur_OutputMessage" />

</wsdlperation>

</wsdlortType>

- <wsdl:binding name="BasicHttpBinding_IIncidentSrv" type="tns:IIncidentSrv">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" />

- <wsdlperation name="ListePourUtilisateur">

<soapperation soapAction="http://tempuri.org/IIncidentSrv/ListePourUtilisateur" style="document" />

- <wsdl:input>

<soap:body use="literal" />

</wsdl:input>

- <wsdlutput>

<soap:body use="literal" />

</wsdlutput>

</wsdlperation>

</wsdl:binding>

- <wsdlervice name="IncidentSrv">

- <wsdlort name="BasicHttpBinding_IIncidentSrv" binding="tns:BasicHttpBinding_IIncidentSrv">

<soap:address location="http://localhost:10827/IncidentListes.svc" />

</wsdlort>

</wsdlervice>

</wsdlefinitions>

"

1) Which URL should I use as the connection string in the dataset wizard ? With or without the "?wsdl" ?

2) How do I write the "<query>" block to obtain the results of the ListePourUtilisateur method as my dataset ?

Okay, this is solved now ... mainly after realizing that the "Cannot execute URL query" error dialog had a small "details" button that actually brought up some useful information.

The problem was actually a namespace incoherence between the WSDL and my <Query>. Once this was fixed, it worked like a charm.

|||

Hey Renaud,

Could you tell me what the exact problem was (what did you entered for Querystring), because we're having the same problem.

Thanks alot,

Jeroen.

|||

Hi Jeroen,

For the query string we simply use the URL of our ".svc" page.

For the query itself, we use the following style :

<Query>
<SoapAction>
http://Namespace/ServiceName </SoapAction>
<Method Namespace="http://Namespace"
Name="ServiceName">
<Parameters>

<Parameter Name="name">
</Parameter>

</Parameters>
</Method>
<ElementPath IgnoreNamespaces="true">MethodNameResponse{}/MethodNameResult{}/ObjectName{Fields}</ElementPath>
</Query>

Hope this helps,

Renaud