Thursday, March 22, 2012
Bugs
you have to call MS Support? Or do they have a free way
to report a bug?First, check the documentation and search the MS Knowledge Base to see if
it's a known issue:
http://support.microsoft.com/defaul...h;en-gb;kbhowto
Use Google to search the archives of the sqlserver newsgroups to see if your
problem has been discussed before.
If you're still not having any luck then post your problem here. If possible
post some some code that will actually reproduce the problem so that others
can test it out and suggest solutions.
You can also go via MS Product Support. If they acknowledge it as an
undocumented bug then you shouldn't be charged for the call.
David Portas
SQL Server MVP
--
Bugs
you have to call MS Support? Or do they have a free way
to report a bug?First, check the documentation and search the MS Knowledge Base to see if
it's a known issue:
http://support.microsoft.com/default.aspx?scid=fh;en-gb;kbhowto
Use Google to search the archives of the sqlserver newsgroups to see if your
problem has been discussed before.
If you're still not having any luck then post your problem here. If possible
post some some code that will actually reproduce the problem so that others
can test it out and suggest solutions.
You can also go via MS Product Support. If they acknowledge it as an
undocumented bug then you shouldn't be charged for the call.
--
David Portas
SQL Server MVP
--
Bugs
you have to call MS Support? Or do they have a free way
to report a bug?
First, check the documentation and search the MS Knowledge Base to see if
it's a known issue:
http://support.microsoft.com/default...;en-gb;kbhowto
Use Google to search the archives of the sqlserver newsgroups to see if your
problem has been discussed before.
If you're still not having any luck then post your problem here. If possible
post some some code that will actually reproduce the problem so that others
can test it out and suggest solutions.
You can also go via MS Product Support. If they acknowledge it as an
undocumented bug then you shouldn't be charged for the call.
David Portas
SQL Server MVP
sql
bug?: two shared data sources, one update effects the other
server, the other points to a development server). One is named MyDB.rdl, the
other is named MyDBDev.rdl. Both of these are SQL Server data sources, and
they use a specific username and password.
I'm using Visual Studio 2003 as my development environment.
Here's the bug. If I change the username or password for one of the data
sources, it updates the other data sources as well. If I change the username
on the MyDB.rdl datasource from Fred to Jill, the MyDBDev.rdl datasource is
changed as well!!
Is this a known bug, or am I doing something wrong? Is there a workaround?
Thanks,
MarcShared data source file would have extention .rds
Could you please provide more details?
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"mhf" <mhf@.discussions.microsoft.com> wrote in message
news:2CABBB0A-9C90-48F5-A94B-9A1E1A0DE9E7@.microsoft.com...
> Is this a bug? I have two shared data sources (one points to a production
> server, the other points to a development server). One is named MyDB.rdl,
> the
> other is named MyDBDev.rdl. Both of these are SQL Server data sources, and
> they use a specific username and password.
> I'm using Visual Studio 2003 as my development environment.
> Here's the bug. If I change the username or password for one of the data
> sources, it updates the other data sources as well. If I change the
> username
> on the MyDB.rdl datasource from Fred to Jill, the MyDBDev.rdl datasource
> is
> changed as well!!
> Is this a known bug, or am I doing something wrong? Is there a workaround?
> Thanks,
> Marc|||Lev,
Thanks for the reply. Yes, I mistyped there, I meant to day .rds files. The
two shared data source files have an extension of .rds and when I change one
(in Visual Studio) it modifies both of them. The SQL login name and passwords
are not stored in the .rds file, so I don't see the actual change persisted
there. I'm not sure where the changes are actually stored.
"Lev Semenets [MSFT]" wrote:
> Shared data source file would have extention .rds
> Could you please provide more details?
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "mhf" <mhf@.discussions.microsoft.com> wrote in message
> news:2CABBB0A-9C90-48F5-A94B-9A1E1A0DE9E7@.microsoft.com...
> > Is this a bug? I have two shared data sources (one points to a production
> > server, the other points to a development server). One is named MyDB.rdl,
> > the
> > other is named MyDBDev.rdl. Both of these are SQL Server data sources, and
> > they use a specific username and password.
> >
> > I'm using Visual Studio 2003 as my development environment.
> >
> > Here's the bug. If I change the username or password for one of the data
> > sources, it updates the other data sources as well. If I change the
> > username
> > on the MyDB.rdl datasource from Fred to Jill, the MyDBDev.rdl datasource
> > is
> > changed as well!!
> >
> > Is this a known bug, or am I doing something wrong? Is there a workaround?
> >
> > Thanks,
> >
> > Marc
>
>|||Would you email those .rds files to me?
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"mhf" <mhf@.discussions.microsoft.com> wrote in message
news:530A9866-1EEC-4CAB-B44A-CD199B3BBD10@.microsoft.com...
> Lev,
> Thanks for the reply. Yes, I mistyped there, I meant to day .rds files.
> The
> two shared data source files have an extension of .rds and when I change
> one
> (in Visual Studio) it modifies both of them. The SQL login name and
> passwords
> are not stored in the .rds file, so I don't see the actual change
> persisted
> there. I'm not sure where the changes are actually stored.
>
> "Lev Semenets [MSFT]" wrote:
>> Shared data source file would have extention .rds
>> Could you please provide more details?
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "mhf" <mhf@.discussions.microsoft.com> wrote in message
>> news:2CABBB0A-9C90-48F5-A94B-9A1E1A0DE9E7@.microsoft.com...
>> > Is this a bug? I have two shared data sources (one points to a
>> > production
>> > server, the other points to a development server). One is named
>> > MyDB.rdl,
>> > the
>> > other is named MyDBDev.rdl. Both of these are SQL Server data sources,
>> > and
>> > they use a specific username and password.
>> >
>> > I'm using Visual Studio 2003 as my development environment.
>> >
>> > Here's the bug. If I change the username or password for one of the
>> > data
>> > sources, it updates the other data sources as well. If I change the
>> > username
>> > on the MyDB.rdl datasource from Fred to Jill, the MyDBDev.rdl
>> > datasource
>> > is
>> > changed as well!!
>> >
>> > Is this a known bug, or am I doing something wrong? Is there a
>> > workaround?
>> >
>> > Thanks,
>> >
>> > Marc
>>
Bug?: rsMultiReportItemsInPageSectionExpression when one report item, but referenced twice
error saying that I've refereced two items. My motivation is the database
field on each page footer. I have a custom assembly instance that stores
the value from the first page, then returns it when I am passing in empty
values. I tried the page number from the globals collection but ran into
#Error...anyway, getting off base. My issue is that the report expression
references a single item twice. Should I be able to do this? If not,
should the error message be more specific?
Expression:
=IIf(IsNothing(ReportItems!txtSchoolNameHidden.Value)=False,
Code.loc.SchoolName(ReportItems!txtSchoolNameHidden.Value),
Code.loc.SchoolName(""))
Error:
[rsMultiReportItemsInPageSectionExpression] The Value expression for the
textbox 'txtSchoolName' refers to more than one report item. An expression
in a page header or footer can refer to only one report item.Submitted bug to Microsoft via Product Feedback
"Steve MunLeeuw" <smunson@.clearwire.net> wrote in message
news:%23RtLLbKNGHA.3728@.tk2msftngp13.phx.gbl...
> When I reference the same report item twice in my footer expression I get
> an error saying that I've refereced two items. My motivation is the
> database field on each page footer. I have a custom assembly instance
> that stores the value from the first page, then returns it when I am
> passing in empty values. I tried the page number from the globals
> collection but ran into #Error...anyway, getting off base. My issue is
> that the report expression references a single item twice. Should I be
> able to do this? If not, should the error message be more specific?
> Expression:
> =IIf(IsNothing(ReportItems!txtSchoolNameHidden.Value)=False,
> Code.loc.SchoolName(ReportItems!txtSchoolNameHidden.Value),
> Code.loc.SchoolName(""))
> Error:
> [rsMultiReportItemsInPageSectionExpression] The Value expression for the
> textbox 'txtSchoolName' refers to more than one report item. An
> expression in a page header or footer can refer to only one report item.
>
Bug?: left outer join in combination with a view
there is a small test case (SQL Server 2000 - 8.00.760):
-- create a small table
create table test1 (nr int null)
insert into test1 values (1)
insert into test1 values (2)
-- now create a view
create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
If you perform this select, the isnull_jn col is always 'J',
although it should be 'N' in the second row:
select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
from test1 left outer join testview on test1.nr = testview.nr
nr jn isnull_jn
-- -- --
1 J J
2 NULL J <<<=== error, should be N!
If you redefine the query to:
select test1.nr, jn, case when jn is null then 'N' else jn end as 'case_jn'
from test1 left outer join testview on test1.nr = testview.nr
nr jn case_jn
-- -- --
1 J J
2 NULL N <<== ok!
everything works fine.
Any suggestions?
--
markusOn Tue, 20 Apr 2004 18:32:32 +0200, mark wrote:
>-- create a small table
>create table test1 (nr int null)
>insert into test1 values (1)
>insert into test1 values (2)
>-- now create a view
>create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
>If you perform this select, the isnull_jn col is always 'J',
>although it should be 'N' in the second row:
>select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
>from test1 left outer join testview on test1.nr = testview.nr
>nr jn isnull_jn
>-- -- --
>1 J J
>2 NULL J <<<=== error, should be N!
>
>If you redefine the query to:
>select test1.nr, jn, case when jn is null then 'N' else jn end as 'case_jn
'
>from test1 left outer join testview on test1.nr = testview.nr
>nr jn case_jn
>-- -- --
>1 J J
>2 NULL N <<== ok!
>everything works fine.
Hi Markus,
Nice one :-)
Looks like a bug to me. You might want to report it to MS.
>Any suggestions?
Yes. Don't use ISNULL. Use COALESCE instead. Three reasons:
1. COALESCE is ANSI-standard, ISNULL is proprietary. That makes
COALESCE more portable. Plus, the support for ISNULL might be
discontinued in a future version of SQL Server.
2. COALESCE is more versatile. With COALESCE, you can get the first
non-NULL of as many arguments as you want. With ISNULL, the same can
only be achieved by nesting.
3. ISNULL apparently produces erroneous results when used in a left
outer join in combination with a view. A guy named Markus recently
posted about this in a newsgroup :-))
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Hi Hugo,
COALESCE has bug problems of it's own:
http://support.microsoft.com/defaul...kb;en-us;317527
If you want to play safe, use CASE for any non-trivial scenarios where you
would use ISNULL or COALESCE.
Jacco Schalkwijk
SQL Server MVP
"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:e2sa80500of69g9q8e4dmijfcqjl9toenc@.
4ax.com...
> On Tue, 20 Apr 2004 18:32:32 +0200, mark wrote:
>
'case_jn'[vbcol=seagreen]
> Hi Markus,
> Nice one :-)
> Looks like a bug to me. You might want to report it to MS.
>
> Yes. Don't use ISNULL. Use COALESCE instead. Three reasons:
> 1. COALESCE is ANSI-standard, ISNULL is proprietary. That makes
> COALESCE more portable. Plus, the support for ISNULL might be
> discontinued in a future version of SQL Server.
> 2. COALESCE is more versatile. With COALESCE, you can get the first
> non-NULL of as many arguments as you want. With ISNULL, the same can
> only be achieved by nesting.
> 3. ISNULL apparently produces erroneous results when used in a left
> outer join in combination with a view. A guy named Markus recently
> posted about this in a newsgroup :-))
>
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)|||On Wed, 21 Apr 2004 15:26:17 +0100, Jacco Schalkwijk wrote:
>Hi Hugo,
>COALESCE has bug problems of it's own:
>http://support.microsoft.com/defaul...kb;en-us;317527
>If you want to play safe, use CASE for any non-trivial scenarios where you
>would use ISNULL or COALESCE.
When I executed the repro query in that article, I didn't get the
error, but the (expected) value of 1. Apparantly, this bug is fixed in
Service Pack 3a.
But thanks for the pointer, anyway - it just shows that it pays to pay
attention to the results of your query. A complicated product like SQL
Server (or any other RDBMS) can never be completely bug-free.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)sql
Bug?: left outer join in combination with a view
there is a small test case (SQL Server 2000 - 8.00.760):
-- create a small table
create table test1 (nr int null)
insert into test1 values (1)
insert into test1 values (2)
-- now create a view
create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
If you perform this select, the isnull_jn col is always 'J',
although it should be 'N' in the second row:
select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
from test1 left outer join testview on test1.nr = testview.nr
nr jn isnull_jn
-- -- --
1 J J
2 NULL J <<<=== error, should be N!
If you redefine the query to:
select test1.nr, jn, case when jn is null then 'N' else jn end as 'case_jn'
from test1 left outer join testview on test1.nr = testview.nr
nr jn case_jn
-- -- --
1 J J
2 NULL N <<== ok!
everything works fine.
Any suggestions?
--
markusThat looks like a bug with ISNULL; I switched it to use COALESCE instead and
it fixed the problem...
Hopefully someone reading this knows how to submit a SQL bug report to MS?
"mark" <wimark@.smsNOSAPM.at> wrote in message
news:#EJS#RvJEHA.620@.tk2msftngp13.phx.gbl...
> Hi,
> there is a small test case (SQL Server 2000 - 8.00.760):
> -- create a small table
> create table test1 (nr int null)
> insert into test1 values (1)
> insert into test1 values (2)
> -- now create a view
> create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
> If you perform this select, the isnull_jn col is always 'J',
> although it should be 'N' in the second row:
> select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
> from test1 left outer join testview on test1.nr = testview.nr
> nr jn isnull_jn
> -- -- --
> 1 J J
> 2 NULL J <<<=== error, should be N!
>
> If you redefine the query to:
> select test1.nr, jn, case when jn is null then 'N' else jn end as
'case_jn'
> from test1 left outer join testview on test1.nr = testview.nr
> nr jn case_jn
> -- -- --
> 1 J J
> 2 NULL N <<== ok!
> everything works fine.
> Any suggestions?
> --
> markus
>|||ISNULL is kind of notoriously NOT the same thing as COALESCE and CASE, so I
was skeptical that this was really a bug. But below is a repro which uses
ISNULL with a view and an "inline view" or derived table.
Now despite any differences between INSULL and COALESCE, these 2 queries
should return the same data. They do not.
-- create a small table
create table test1 (nr int null)
insert into test1 values (1)
insert into test1 values (2)
-- now create a view
create view testview as select nr, 'J' jn from test1 where nr = 1
select
test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
from test1
left outer join (select nr, 'J' jn from test1 where nr = 1) testview
on test1.nr = testview.nr
where test1.nr=2
select
test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
from test1
left outer join testview
on test1.nr = testview.nr
where test1.nr=2
--
nr jn isnull_jn
2 N
(1 row(s) affected)
nr jn isnull_jn
2 J
(1 row(s) affected)
David
Should definitely return the same data
"Adam Machanic" <amachanic@.air-worldwide.nospamallowed.com> wrote in message
news:ebxMLqvJEHA.3120@.TK2MSFTNGP11.phx.gbl...
> That looks like a bug with ISNULL; I switched it to use COALESCE instead
and
> it fixed the problem...
> Hopefully someone reading this knows how to submit a SQL bug report to MS?
>
> "mark" <wimark@.smsNOSAPM.at> wrote in message
> news:#EJS#RvJEHA.620@.tk2msftngp13.phx.gbl...
> > Hi,
> >
> > there is a small test case (SQL Server 2000 - 8.00.760):
> >
> > -- create a small table
> > create table test1 (nr int null)
> > insert into test1 values (1)
> > insert into test1 values (2)
> > -- now create a view
> > create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
> >
> > If you perform this select, the isnull_jn col is always 'J',
> > although it should be 'N' in the second row:
> > select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
> > from test1 left outer join testview on test1.nr = testview.nr
> > nr jn isnull_jn
> > -- -- --
> > 1 J J
> > 2 NULL J <<<=== error, should be N!
> >
> >
> > If you redefine the query to:
> > select test1.nr, jn, case when jn is null then 'N' else jn end as
> 'case_jn'
> > from test1 left outer join testview on test1.nr = testview.nr
> > nr jn case_jn
> > -- -- --
> > 1 J J
> > 2 NULL N <<== ok!
> > everything works fine.
> >
> > Any suggestions?
> > --
> > markus
> >
> >
>|||On Tue, 20 Apr 2004 18:32:32 +0200, mark wrote:
>-- create a small table
>create table test1 (nr int null)
>insert into test1 values (1)
>insert into test1 values (2)
>-- now create a view
>create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
>If you perform this select, the isnull_jn col is always 'J',
>although it should be 'N' in the second row:
>select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
>from test1 left outer join testview on test1.nr = testview.nr
>nr jn isnull_jn
>-- -- --
>1 J J
>2 NULL J <<<=== error, should be N!
>
>If you redefine the query to:
>select test1.nr, jn, case when jn is null then 'N' else jn end as 'case_jn'
>from test1 left outer join testview on test1.nr = testview.nr
>nr jn case_jn
>-- -- --
>1 J J
>2 NULL N <<== ok!
>everything works fine.
Hi Markus,
Nice one :-)
Looks like a bug to me. You might want to report it to MS.
>Any suggestions?
Yes. Don't use ISNULL. Use COALESCE instead. Three reasons:
1. COALESCE is ANSI-standard, ISNULL is proprietary. That makes
COALESCE more portable. Plus, the support for ISNULL might be
discontinued in a future version of SQL Server.
2. COALESCE is more versatile. With COALESCE, you can get the first
non-NULL of as many arguments as you want. With ISNULL, the same can
only be achieved by nesting.
3. ISNULL apparently produces erroneous results when used in a left
outer join in combination with a view. A guy named Markus recently
posted about this in a newsgroup :-))
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Hi Hugo,
COALESCE has bug problems of it's own:
http://support.microsoft.com/default.aspx?scid=kb;en-us;317527
If you want to play safe, use CASE for any non-trivial scenarios where you
would use ISNULL or COALESCE.
--
Jacco Schalkwijk
SQL Server MVP
"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:e2sa80500of69g9q8e4dmijfcqjl9toenc@.4ax.com...
> On Tue, 20 Apr 2004 18:32:32 +0200, mark wrote:
> >-- create a small table
> >create table test1 (nr int null)
> >insert into test1 values (1)
> >insert into test1 values (2)
> >-- now create a view
> >create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
> >
> >If you perform this select, the isnull_jn col is always 'J',
> >although it should be 'N' in the second row:
> >select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
> >from test1 left outer join testview on test1.nr = testview.nr
> >nr jn isnull_jn
> >-- -- --
> >1 J J
> >2 NULL J <<<=== error, should be N!
> >
> >
> >If you redefine the query to:
> >select test1.nr, jn, case when jn is null then 'N' else jn end as
'case_jn'
> >from test1 left outer join testview on test1.nr = testview.nr
> >nr jn case_jn
> >-- -- --
> >1 J J
> >2 NULL N <<== ok!
> >everything works fine.
> Hi Markus,
> Nice one :-)
> Looks like a bug to me. You might want to report it to MS.
> >
> >Any suggestions?
> Yes. Don't use ISNULL. Use COALESCE instead. Three reasons:
> 1. COALESCE is ANSI-standard, ISNULL is proprietary. That makes
> COALESCE more portable. Plus, the support for ISNULL might be
> discontinued in a future version of SQL Server.
> 2. COALESCE is more versatile. With COALESCE, you can get the first
> non-NULL of as many arguments as you want. With ISNULL, the same can
> only be achieved by nesting.
> 3. ISNULL apparently produces erroneous results when used in a left
> outer join in combination with a view. A guy named Markus recently
> posted about this in a newsgroup :-))
>
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)|||On Wed, 21 Apr 2004 15:26:17 +0100, Jacco Schalkwijk wrote:
>Hi Hugo,
>COALESCE has bug problems of it's own:
>http://support.microsoft.com/default.aspx?scid=kb;en-us;317527
>If you want to play safe, use CASE for any non-trivial scenarios where you
>would use ISNULL or COALESCE.
When I executed the repro query in that article, I didn't get the
error, but the (expected) value of 1. Apparantly, this bug is fixed in
Service Pack 3a.
But thanks for the pointer, anyway - it just shows that it pays to pay
attention to the results of your query. A complicated product like SQL
Server (or any other RDBMS) can never be completely bug-free.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)
Bug?: left outer join in combination with a view
there is a small test case (SQL Server 2000 - 8.00.760):
-- create a small table
create table test1 (nr int null)
insert into test1 values (1)
insert into test1 values (2)
-- now create a view
create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
If you perform this select, the isnull_jn col is always 'J',
although it should be 'N' in the second row:
select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
from test1 left outer join testview on test1.nr = testview.nr
nr jn isnull_jn
-- -- --
1 J J
2 NULL J <<<=== error, should be N!
If you redefine the query to:
select test1.nr, jn, case when jn is null then 'N' else jn end as 'case_jn'
from test1 left outer join testview on test1.nr = testview.nr
nr jn case_jn
-- -- --
1 J J
2 NULL N <<== ok!
everything works fine.
Any suggestions?
markus
On Tue, 20 Apr 2004 18:32:32 +0200, mark wrote:
>-- create a small table
>create table test1 (nr int null)
>insert into test1 values (1)
>insert into test1 values (2)
>-- now create a view
>create view testview (nr, jn ) as select nr, 'J' from test1 where nr = 1
>If you perform this select, the isnull_jn col is always 'J',
>although it should be 'N' in the second row:
>select test1.nr, jn , isnull( jn, 'N') as 'isnull_jn'
>from test1 left outer join testview on test1.nr = testview.nr
>nr jn isnull_jn
>-- -- --
>1 J J
>2 NULL J <<<=== error, should be N!
>
>If you redefine the query to:
>select test1.nr, jn, case when jn is null then 'N' else jn end as 'case_jn'
>from test1 left outer join testview on test1.nr = testview.nr
>nr jn case_jn
>-- -- --
>1 J J
>2 NULL N <<== ok!
>everything works fine.
Hi Markus,
Nice one :-)
Looks like a bug to me. You might want to report it to MS.
>Any suggestions?
Yes. Don't use ISNULL. Use COALESCE instead. Three reasons:
1. COALESCE is ANSI-standard, ISNULL is proprietary. That makes
COALESCE more portable. Plus, the support for ISNULL might be
discontinued in a future version of SQL Server.
2. COALESCE is more versatile. With COALESCE, you can get the first
non-NULL of as many arguments as you want. With ISNULL, the same can
only be achieved by nesting.
3. ISNULL apparently produces erroneous results when used in a left
outer join in combination with a view. A guy named Markus recently
posted about this in a newsgroup :-))
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||Hi Hugo,
COALESCE has bug problems of it's own:
http://support.microsoft.com/default...b;en-us;317527
If you want to play safe, use CASE for any non-trivial scenarios where you
would use ISNULL or COALESCE.
Jacco Schalkwijk
SQL Server MVP
"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:e2sa80500of69g9q8e4dmijfcqjl9toenc@.4ax.com... [vbcol=seagreen]
> On Tue, 20 Apr 2004 18:32:32 +0200, mark wrote:
'case_jn'
> Hi Markus,
> Nice one :-)
> Looks like a bug to me. You might want to report it to MS.
>
> Yes. Don't use ISNULL. Use COALESCE instead. Three reasons:
> 1. COALESCE is ANSI-standard, ISNULL is proprietary. That makes
> COALESCE more portable. Plus, the support for ISNULL might be
> discontinued in a future version of SQL Server.
> 2. COALESCE is more versatile. With COALESCE, you can get the first
> non-NULL of as many arguments as you want. With ISNULL, the same can
> only be achieved by nesting.
> 3. ISNULL apparently produces erroneous results when used in a left
> outer join in combination with a view. A guy named Markus recently
> posted about this in a newsgroup :-))
>
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)
|||On Wed, 21 Apr 2004 15:26:17 +0100, Jacco Schalkwijk wrote:
>Hi Hugo,
>COALESCE has bug problems of it's own:
>http://support.microsoft.com/default...b;en-us;317527
>If you want to play safe, use CASE for any non-trivial scenarios where you
>would use ISNULL or COALESCE.
When I executed the repro query in that article, I didn't get the
error, but the (expected) value of 1. Apparantly, this bug is fixed in
Service Pack 3a.
But thanks for the pointer, anyway - it just shows that it pays to pay
attention to the results of your query. A complicated product like SQL
Server (or any other RDBMS) can never be completely bug-free.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
BUG?: Deploy to non-trusted SSL site will fail
(certificate not in Trusted Root) the deployment will fail.
It would be better to pop-up the dialog to choose to trust or not (like the
dialog in IE).Hi Dinko:
I take it you are deploying with the web service? It's a pain, but you
can create a class implementing the ICertificatePolicy class to
determine what certificates you'll allow your script / application to
trust.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemneticertificatepolicyclasstopic.asp
--
Scott
http://www.OdeToCode.com/blogs/scott/
On Tue, 2 Nov 2004 14:29:34 +0100, "Dinko Deranja" <dd@.dd.dd> wrote:
>If I try to deploy report solution to SSL site which I do not trust
>(certificate not in Trusted Root) the deployment will fail.
>It would be better to pop-up the dialog to choose to trust or not (like the
>dialog in IE).
>
BUG? Unable to Contact non default instance of SQL server
think i have found a resolution to a problem which has been ocurring
intermittantly on new sql server installations for some time. The symptoms
are being unable to see or connect to a named instance of sql server when
there is a default instance running also. I have spotted this behaviour in
both workstation installed versions and windows 2000 server installations.
It appears the problem is due to the named instance using tcpip with a port
of 1433 the same as the default instance. One of my machines which has a
named instance which can be connected to, has a Tcpip port of 1104. So i
guess the installation procedure is supposed to assign an unused tcpip port
when creating new instances (but this isn't occurring sometimes).
I changed the port to 1104 and was then able to connect correctly. I also
tried removing tcpip and connecting only using named pipes and this worked
also.
The latest machine build (which had this issue) was installed by installing
the default instance then the named instance and then servicepacking the
default and then the named instance with service pack3.
Thanks
TimBwhat's your connecting client's mdac-level ?
jobi
"timb" <timb@.test.com> wrote in message
news:u8fAuakjDHA.1740@.TK2MSFTNGP12.phx.gbl...
> Hi,
> think i have found a resolution to a problem which has been ocurring
> intermittantly on new sql server installations for some time. The
symptoms
> are being unable to see or connect to a named instance of sql server when
> there is a default instance running also. I have spotted this behaviour in
> both workstation installed versions and windows 2000 server installations.
> It appears the problem is due to the named instance using tcpip with a
port
> of 1433 the same as the default instance. One of my machines which has a
> named instance which can be connected to, has a Tcpip port of 1104. So i
> guess the installation procedure is supposed to assign an unused tcpip
port
> when creating new instances (but this isn't occurring sometimes).
> I changed the port to 1104 and was then able to connect correctly. I
also
> tried removing tcpip and connecting only using named pipes and this worked
> also.
> The latest machine build (which had this issue) was installed by
installing
> the default instance then the named instance and then servicepacking the
> default and then the named instance with service pack3.
>
> Thanks
> TimB
>|||What does MDAC have to do with it?
"jobi" <jobi@.reply2.group> wrote in message
news:bm3ccv$1si$1@.reader08.wxs.nl...
> what's your connecting client's mdac-level ?
> jobi
> "timb" <timb@.test.com> wrote in message
> news:u8fAuakjDHA.1740@.TK2MSFTNGP12.phx.gbl...
> > Hi,
> > think i have found a resolution to a problem which has been ocurring
> > intermittantly on new sql server installations for some time. The
> symptoms
> > are being unable to see or connect to a named instance of sql server
when
> > there is a default instance running also. I have spotted this behaviour
in
> > both workstation installed versions and windows 2000 server
installations.
> > It appears the problem is due to the named instance using tcpip with a
> port
> > of 1433 the same as the default instance. One of my machines which has
a
> > named instance which can be connected to, has a Tcpip port of 1104. So
i
> > guess the installation procedure is supposed to assign an unused tcpip
> port
> > when creating new instances (but this isn't occurring sometimes).
> >
> > I changed the port to 1104 and was then able to connect correctly. I
> also
> > tried removing tcpip and connecting only using named pipes and this
worked
> > also.
> >
> > The latest machine build (which had this issue) was installed by
> installing
> > the default instance then the named instance and then servicepacking the
> > default and then the named instance with service pack3.
> >
> >
> > Thanks
> >
> > TimB
> >
> >
>|||You have to have at least mdac 2.6 to be able to detect virtual instances by
their instancename if they don't run on port 1433.
Search KB and BOL !
jobi
"timb" <timb@.test.com> wrote in message
news:#SLUYGojDHA.2232@.TK2MSFTNGP09.phx.gbl...
> What does MDAC have to do with it?
> "jobi" <jobi@.reply2.group> wrote in message
> news:bm3ccv$1si$1@.reader08.wxs.nl...
> > what's your connecting client's mdac-level ?
> >
> > jobi
> > "timb" <timb@.test.com> wrote in message
> > news:u8fAuakjDHA.1740@.TK2MSFTNGP12.phx.gbl...
> > > Hi,
> > > think i have found a resolution to a problem which has been
ocurring
> > > intermittantly on new sql server installations for some time. The
> > symptoms
> > > are being unable to see or connect to a named instance of sql server
> when
> > > there is a default instance running also. I have spotted this
behaviour
> in
> > > both workstation installed versions and windows 2000 server
> installations.
> > > It appears the problem is due to the named instance using tcpip with a
> > port
> > > of 1433 the same as the default instance. One of my machines which
has
> a
> > > named instance which can be connected to, has a Tcpip port of 1104.
So
> i
> > > guess the installation procedure is supposed to assign an unused
tcpip
> > port
> > > when creating new instances (but this isn't occurring sometimes).
> > >
> > > I changed the port to 1104 and was then able to connect correctly.
I
> > also
> > > tried removing tcpip and connecting only using named pipes and this
> worked
> > > also.
> > >
> > > The latest machine build (which had this issue) was installed by
> > installing
> > > the default instance then the named instance and then servicepacking
the
> > > default and then the named instance with service pack3.
> > >
> > >
> > > Thanks
> > >
> > > TimB
> > >
> > >
> >
> >
>|||Hi Jobi,
no both machines are mdac 2.7. If you read my initial post you
can see that i changed the port to be different to the default port (1433)
and i could then see the instance! i.e. this is due to the sql server
installation for the named instance assigning it a port which is already in
use rather than using a new port.
Tim B
"jobi" <jobi@.reply2.group> wrote in message
news:bm5ke4$jrs$1@.reader08.wxs.nl...
> You have to have at least mdac 2.6 to be able to detect virtual instances
by
> their instancename if they don't run on port 1433.
> Search KB and BOL !
> jobi
> "timb" <timb@.test.com> wrote in message
> news:#SLUYGojDHA.2232@.TK2MSFTNGP09.phx.gbl...
> > What does MDAC have to do with it?
> >
> > "jobi" <jobi@.reply2.group> wrote in message
> > news:bm3ccv$1si$1@.reader08.wxs.nl...
> > > what's your connecting client's mdac-level ?
> > >
> > > jobi
> > > "timb" <timb@.test.com> wrote in message
> > > news:u8fAuakjDHA.1740@.TK2MSFTNGP12.phx.gbl...
> > > > Hi,
> > > > think i have found a resolution to a problem which has been
> ocurring
> > > > intermittantly on new sql server installations for some time. The
> > > symptoms
> > > > are being unable to see or connect to a named instance of sql server
> > when
> > > > there is a default instance running also. I have spotted this
> behaviour
> > in
> > > > both workstation installed versions and windows 2000 server
> > installations.
> > > > It appears the problem is due to the named instance using tcpip with
a
> > > port
> > > > of 1433 the same as the default instance. One of my machines which
> has
> > a
> > > > named instance which can be connected to, has a Tcpip port of 1104.
> So
> > i
> > > > guess the installation procedure is supposed to assign an unused
> tcpip
> > > port
> > > > when creating new instances (but this isn't occurring sometimes).
> > > >
> > > > I changed the port to 1104 and was then able to connect correctly.
> I
> > > also
> > > > tried removing tcpip and connecting only using named pipes and this
> > worked
> > > > also.
> > > >
> > > > The latest machine build (which had this issue) was installed by
> > > installing
> > > > the default instance then the named instance and then servicepacking
> the
> > > > default and then the named instance with service pack3.
> > > >
> > > >
> > > > Thanks
> > > >
> > > > TimB
> > > >
> > > >
> > >
> > >
> >
> >
>
Bug? Transfer SQL Server Objects Task - error when copying Views
I'm trying to copy data over using a Transfer SQL Server Objects Task however I get problems trying to copy over views. I get the similar error (pre sp1) when using import/export wizard and copying over views. Now with SP1 the views just don't transfer. I'm transferring from SQL 2005 to SQL 2005. The error I get is:
Error: 0xC002F363 at Transfer Data (NEW), Transfer SQL Server Objects Task: Table "vw_XXXX" does not exist at the source. Task failed: Transfer Data (NEW)
I know the view exists at the source because:
A) I can select it in the Views List Collection within the Transfer SQL Server Objects Task
B) I'm using the view on the source
Somehow the views are not transferring. Anyone have any ideas?
I just noticed that SP1 import/export wizard copies the views to the destination as tables!!! What is going on here?!?! Is this why I'm having problems in the Transfer SQL Server Objects Task as stated above?|||Also get Error: 0x80004005 on Microsoft SQL Native Client when using this Task about 30% of the time.|||If you do a search you will find that the Transfer Objects Task is pretty buggy. I would avoid it until those issues are resolved.|||So has this been fixed? I'm getting the same error:
[Transfer SQL Server Objects Task] Error: Table "tbl_BOL_ShipID" does not exist at the source.
I know the referenced table exists at the source.
|||Do you have the CopySchema option set to true? This is a frequent source of these error messages.|||I've use the same way.
This Task checks the Objects and Columns casesensitive.
So all Objects and Columns must be identically named.
|||I believe some work was done on the case sensitivity issue in SP2. Are you still seeing this problem after upgrading?sqlBug? Transfer SQL Server Objects Task - error when copying Views
I'm trying to copy data over using a Transfer SQL Server Objects Task however I get problems trying to copy over views. I get the similar error (pre sp1) when using import/export wizard and copying over views. Now with SP1 the views just don't transfer. I'm transferring from SQL 2005 to SQL 2005. The error I get is:
Error: 0xC002F363 at Transfer Data (NEW), Transfer SQL Server Objects Task: Table "vw_XXXX" does not exist at the source. Task failed: Transfer Data (NEW)
I know the view exists at the source because:
A) I can select it in the Views List Collection within the Transfer SQL Server Objects Task
B) I'm using the view on the source
Somehow the views are not transferring. Anyone have any ideas?
I just noticed that SP1 import/export wizard copies the views to the destination as tables!!! What is going on here?!?! Is this why I'm having problems in the Transfer SQL Server Objects Task as stated above?|||Also get Error: 0x80004005 on Microsoft SQL Native Client when using this Task about 30% of the time.|||If you do a search you will find that the Transfer Objects Task is pretty buggy. I would avoid it until those issues are resolved.|||So has this been fixed? I'm getting the same error:
[Transfer SQL Server Objects Task] Error: Table "tbl_BOL_ShipID" does not exist at the source.
I know the referenced table exists at the source.
|||Do you have the CopySchema option set to true? This is a frequent source of these error messages.|||I've use the same way.
This Task checks the Objects and Columns casesensitive.
So all Objects and Columns must be identically named.
|||I believe some work was done on the case sensitivity issue in SP2. Are you still seeing this problem after upgrading?Bug? Transfer SQL Server Objects Task - error when copying Views
I'm trying to copy data over using a Transfer SQL Server Objects Task however I get problems trying to copy over views. I get the similar error (pre sp1) when using import/export wizard and copying over views. Now with SP1 the views just don't transfer. I'm transferring from SQL 2005 to SQL 2005. The error I get is:
Error: 0xC002F363 at Transfer Data (NEW), Transfer SQL Server Objects Task: Table "vw_XXXX" does not exist at the source. Task failed: Transfer Data (NEW)
I know the view exists at the source because:
A) I can select it in the Views List Collection within the Transfer SQL Server Objects Task
B) I'm using the view on the source
Somehow the views are not transferring. Anyone have any ideas?
I just noticed that SP1 import/export wizard copies the views to the destination as tables!!! What is going on here?!?! Is this why I'm having problems in the Transfer SQL Server Objects Task as stated above?|||Also get Error: 0x80004005 on Microsoft SQL Native Client when using this Task about 30% of the time.|||If you do a search you will find that the Transfer Objects Task is pretty buggy. I would avoid it until those issues are resolved.|||So has this been fixed? I'm getting the same error:
[Transfer SQL Server Objects Task] Error: Table "tbl_BOL_ShipID" does not exist at the source.
I know the referenced table exists at the source.
|||Do you have the CopySchema option set to true? This is a frequent source of these error messages.|||I've use the same way.
This Task checks the Objects and Columns casesensitive.
So all Objects and Columns must be identically named.
|||I believe some work was done on the case sensitivity issue in SP2. Are you still seeing this problem after upgrading?Bug? Transfer SQL Server Objects Task - error when copying Views
I'm trying to copy data over using a Transfer SQL Server Objects Task however I get problems trying to copy over views. I get the similar error (pre sp1) when using import/export wizard and copying over views. Now with SP1 the views just don't transfer. I'm transferring from SQL 2005 to SQL 2005. The error I get is:
Error: 0xC002F363 at Transfer Data (NEW), Transfer SQL Server Objects Task: Table "vw_XXXX" does not exist at the source. Task failed: Transfer Data (NEW)
I know the view exists at the source because:
A) I can select it in the Views List Collection within the Transfer SQL Server Objects Task
B) I'm using the view on the source
Somehow the views are not transferring. Anyone have any ideas?
I just noticed that SP1 import/export wizard copies the views to the destination as tables!!! What is going on here?!?! Is this why I'm having problems in the Transfer SQL Server Objects Task as stated above?|||Also get Error: 0x80004005 on Microsoft SQL Native Client when using this Task about 30% of the time.|||If you do a search you will find that the Transfer Objects Task is pretty buggy. I would avoid it until those issues are resolved.|||So has this been fixed? I'm getting the same error:
[Transfer SQL Server Objects Task] Error: Table "tbl_BOL_ShipID" does not exist at the source.
I know the referenced table exists at the source.
|||Do you have the CopySchema option set to true? This is a frequent source of these error messages.|||I've use the same way.
This Task checks the Objects and Columns casesensitive.
So all Objects and Columns must be identically named.
|||I believe some work was done on the case sensitivity issue in SP2. Are you still seeing this problem after upgrading?Bug? Report Builder returning only unique records!
Example:
TransID Type TransQuantity
1 CS 4
2 CS 4
3 CP 2
4 CN 3
Adding the above fields to the report builder canvas will return 4 rows. However, if I were to add only Type and TransQuantity to the canvas as such, Report Builder will only return 3 rows:
Type TransQuantity
CS 4
CP 2
CN 3
Is there any way to have Report Builder return the actual number of records? Our users often will export the results from Report Builder into Excel to slice and dice the data, and with the functionality the Report Builder has right now, incorrect values will be certain.
Thanks,
Taurkon
You need to be aware of what Report Builder is grouping on. If you don't want rows based on distinct values, add the ID field first to make sure you get an entity group, then remove it later.
See this blog post for more info:
http://blogs.msdn.com/bobmeyers/archive/2006/12/20/getting-grouping-right-in-report-builder.aspx
Hope this helps!
|||Thanks Bob for your response.bug? outlook web access
RS2000. Subscription delivers email with PDF attachment.
When the email is opened in Outlook client, the attachment is there and
working as expected.
Problem:
When the email is opened in the Outlook Web client (OWA), the paperclip is
there identifying the attachment, but when the email is opened, there is no
attachment.
It seems to be happening only with attachment coming from reporting
services. I can send an email with another PDF file and open it fine. The
PDF files are small in size so I do not think it is a size proble.I just tried this and also was not able to see the .pdf file. This appears
to be a bug to me. I would contact customer support to help get this issue
resolved.
--
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"chicagoclone" <chicagoclone@.discussions.microsoft.com> wrote in message
news:B4C39492-DC1A-4FA0-8198-F1727A020B34@.microsoft.com...
> Scenerio:
> RS2000. Subscription delivers email with PDF attachment.
> When the email is opened in Outlook client, the attachment is there and
> working as expected.
> Problem:
> When the email is opened in the Outlook Web client (OWA), the paperclip is
> there identifying the attachment, but when the email is opened, there is
> no
> attachment.
> It seems to be happening only with attachment coming from reporting
> services. I can send an email with another PDF file and open it fine.
> The
> PDF files are small in size so I do not think it is a size proble.|||Daniel,
Thank you for the response.
"Daniel Reib [MSFT]" wrote:
> I just tried this and also was not able to see the .pdf file. This appears
> to be a bug to me. I would contact customer support to help get this issue
> resolved.
> --
> -Daniel
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "chicagoclone" <chicagoclone@.discussions.microsoft.com> wrote in message
> news:B4C39492-DC1A-4FA0-8198-F1727A020B34@.microsoft.com...
> >
> > Scenerio:
> > RS2000. Subscription delivers email with PDF attachment.
> > When the email is opened in Outlook client, the attachment is there and
> > working as expected.
> >
> > Problem:
> > When the email is opened in the Outlook Web client (OWA), the paperclip is
> > there identifying the attachment, but when the email is opened, there is
> > no
> > attachment.
> >
> > It seems to be happening only with attachment coming from reporting
> > services. I can send an email with another PDF file and open it fine.
> > The
> > PDF files are small in size so I do not think it is a size proble.
>
>
BUG? or intended that in order to move or rename reports....
...anywhere in the folder structure a person must be set up as a Content Manager at the Reporting Services ROOT (and at every level of the folder hierarchy down to the level that they are moving/renaming)?
Sure, you can remove them from the role in other folders where they should not be moving or renaming objects, but it seems you still have to have them at the root (and down the chain), which gives them far more capabilities than you might intend.
Jeff
After further examination into this problem, it appears in order for someone to move or rename a report or file, they need two things:
1) Content Manager role for the folder they are moving to/from or renaming files
2) Content Manager role for the root RS folder, but not up or down the chain between the root or the folder above.
This has really got to be a bug, as I can't imagine Microsoft doing this on purpose.
Jeff
Bug? No WSDL information fo a WEBMETHOD that points to a table-value function
Hello all,
I'm trying to create a web service that merely exposes a table value function. I have a dummy function that looks like this (in a DB called ReportingDB):
USE [ReportingDB];
DROP function [dbo].[TestFN];
GO
CREATE FUNCTION [dbo].[TestFN] ()
RETURNS
@.Table_Var TABLE (c1 int, c2 int)
AS
BEGIN
RETURN
END;
GO
My web service definition looks like this:
DROP ENDPOINT sql;
go
CREATE ENDPOINT sql
STATE = STARTED
AS HTTP(
PATH = '/sql',
AUTHENTICATION = (INTEGRATED ),
PORTS = ( CLEAR ),
CLEAR_PORT = 90,
SITE = 'mypc'
)
FOR SOAP (
WEBMETHOD 'TestFN'
(name='ReportingDB.dbo.TestFN', SCHEMA=STANDARD),
WSDL = DEFAULT,
SCHEMA = STANDARD,
DATABASE = 'ReportingDB',
NAMESPACE = 'http://tempUri.org/'
);
go
Everything succeeds, however, the problem is that the TestFN function is not visible in the generated WSDL (http://mypc:90/sql?wsdl). If I do the same with a stored procedure instead of a function, then it works as expected, so it seems that I'm missing something or that this is a bug of SQL Server 2005.
Could somebody please shed some light on this issue?
Regards,
Ianier
Hi imj,I think this comes from the type of function that you used. Your TestFN is a Table-valued function. I tried it with a Scalar-valued function, and it worked, the method is noted in the wsdl.
Here's my sample code:
DROP function [dbo].[TestFN];
GO
CREATE FUNCTION TestFN (@.DATE datetime)
RETURNS int
AS
BEGIN
DECLARE @.retVal int
SET @.retVal=1
RETURN(@.retVal)
END
GO
DROP ENDPOINT sql;
go
CREATE ENDPOINT sql
STATE = STARTED
AS HTTP(
PATH = '/sql/test',
AUTHENTICATION = (INTEGRATED ),
PORTS = ( CLEAR ),
CLEAR_PORT = 90,
SITE = 'mypc.domain.com'
)
FOR SOAP (
WEBMETHOD
'http://tempuri.org/'.'TestFN'
(NAME = 'ReportingDB.dbo.TestFN'),
BATCHES = ENABLED,
WSDL = DEFAULT
)
go
/*GRANT CONNECT ON ENDPOINT::sql TO [xxx\yyy]*/
Best regards,
Marcus
Then it may be a SQL Server bug, since the CREATE ENDPOINT command succeeds. Should I get no answer here, I will open a bug report about this.
The reason why I would like to use table-value functions instead of stored procedures is that, since the metadata for table-value functions results is known in advance, I was expecting to see a typed dataset (or array) in the WSDL. That would let me use my function from, say, InfoPath.
Regards,
Ianier|||Hi again,
FYI, I sent a bug report: http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=9e1e9b79-079d-40eb-b3f8-441432a26cbc
Nevertheless, it's hard for me to believe that such a serious issue escaped Microsoft's testing, so I'm still hoping that I'm missing something obvious.
Regards,
Ianier|||SQL Server's SOAP does not support table valued functions unfortunately. This is why it's not working. I found this out by talking to one of the testers. I cannot find where this is mentioned in the docs yet.|||Hello,
Thanks for the info.
That would be a major disapointment. This limitation is not documented and CREATE ENDPOINT reports no error, so this must be either a bug or an "undocumented odd behavior", which is the same.
IMO, not allowing table-value functions in a SOAP endpoint makes the WS feature extremely limited, if useful at all.
I'll come back to this group as soon as I get some feedback on my bug report.
Regards,
Ianier|||
The SQL 2005 Books Online documentation does have a statement stating that Table Value Functions are not supported in Native XML Web Services. Under the "Guidelines and Limitations in Native XML Web Services" topic (ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/8907005f-7f9b-4f53-80b8-f42729caf86b.htm), there's a bullet point saying:
Table valued user-defined functions are not supported.|||Thank you Jimmy,In that case CREATE ENDPOINT should not succeed. This is definitely a bug.
Regards,
Ianier|||
Hi Ianier,
Thanks for the feedback.
SQL 2005 actually allows the "CREATE ENDPOINT" query to be executed before any of the webmethods are created.
ie.
CREATE ENDPOINT sql
STATE = STARTED
AS HTTP(
PATH = '/sql',
AUTHENTICATION = (INTEGRATED ),
PORTS = ( CLEAR ),
CLEAR_PORT = 90,
SITE = 'mypc'
)
FOR SOAP (
WEBMETHOD 'TestFN'
(name='ReportingDB.dbo.TestFN', SCHEMA=STANDARD),
WSDL = DEFAULT,
SCHEMA = STANDARD,
DATABASE = 'ReportingDB',
NAMESPACE = 'http://tempUri.org/'
);
go
CREATE FUNCTION [dbo].[TestFN] ()
RETURNS
@.Table_Var TABLE (c1 int, c2 int)
AS
BEGIN
RETURN
END;
GO
In this scenario is would not be possible for the CREATE ENDPOINT query to verify what the webmethod is. You can argue that this should be a bug as well, but the current behavior provides a more flexible system. Suppose we were strict about requiring the webmethods to be created before the CREATE ENDPOINT query, what would happen if after the stored procedure or function was created, someone went and ALTER it or even DELETE it? Should the different endpoints to magically re-verify that the new version of the webmethod is still valid or even there?
The current mechanism allows SQL to verify at execution/run time that the methods are valid and the user has the proper permissions.
Hope that addresses some of your concerns.
Jimmy Wu [MSFT]
Hi Jimmy,
Thanks for the information.
Common sense tells me that if the function exists and is not of a supported type (i.e. a table-value one) then CREATE ENDPOINT should fail. After all, CREATE ENDPOINT fails, for example, when trying to bind a WEBMETHOD to a view because views are not supported.
If someone ALTERs or DELETEs the function afterwards in a way that is not compatible with the endpoint, either of the following should happen:
Option 1: give an error explaining that the WEBMETHOD should be modified first (i.e. there's a dependency).
Option 2: delete the WEBMETHOD automatically and give a warning to the user.
Regards,
Ianier
sqlBug? No WSDL information fo a WEBMETHOD that points to a table-value function
Hello all,
I'm trying to create a web service that merely exposes a table value function. I have a dummy function that looks like this (in a DB called ReportingDB):
USE [ReportingDB];
DROP function [dbo].[TestFN];
GO
CREATE FUNCTION [dbo].[TestFN] ()
RETURNS
@.Table_Var TABLE (c1 int, c2 int)
AS
BEGIN
RETURN
END;
GO
My web service definition looks like this:
DROP ENDPOINT sql;
go
CREATE ENDPOINT sql
STATE = STARTED
AS HTTP(
PATH = '/sql',
AUTHENTICATION = (INTEGRATED ),
PORTS = ( CLEAR ),
CLEAR_PORT = 90,
SITE = 'mypc'
)
FOR SOAP (
WEBMETHOD 'TestFN'
(name='ReportingDB.dbo.TestFN', SCHEMA=STANDARD),
WSDL = DEFAULT,
SCHEMA = STANDARD,
DATABASE = 'ReportingDB',
NAMESPACE = 'http://tempUri.org/'
);
go
Everything succeeds, however, the problem is that the TestFN function is not visible in the generated WSDL (http://mypc:90/sql?wsdl). If I do the same with a stored procedure instead of a function, then it works as expected, so it seems that I'm missing something or that this is a bug of SQL Server 2005.
Could somebody please shed some light on this issue?
Regards,
Ianier
Hi imj,I think this comes from the type of function that you used. Your TestFN is a Table-valued function. I tried it with a Scalar-valued function, and it worked, the method is noted in the wsdl.
Here's my sample code:
DROP function [dbo].[TestFN];
GO
CREATE FUNCTION TestFN (@.DATE datetime)
RETURNS int
AS
BEGIN
DECLARE @.retVal int
SET @.retVal=1
RETURN(@.retVal)
END
GO
DROP ENDPOINT sql;
go
CREATE ENDPOINT sql
STATE = STARTED
AS HTTP(
PATH = '/sql/test',
AUTHENTICATION = (INTEGRATED ),
PORTS = ( CLEAR ),
CLEAR_PORT = 90,
SITE = 'mypc.domain.com'
)
FOR SOAP (
WEBMETHOD
'http://tempuri.org/'.'TestFN'
(NAME = 'ReportingDB.dbo.TestFN'),
BATCHES = ENABLED,
WSDL = DEFAULT
)
go
/*GRANT CONNECT ON ENDPOINT::sql TO [xxx\yyy]*/
Best regards,
Marcus
Then it may be a SQL Server bug, since the CREATE ENDPOINT command succeeds. Should I get no answer here, I will open a bug report about this.
The reason why I would like to use table-value functions instead of stored procedures is that, since the metadata for table-value functions results is known in advance, I was expecting to see a typed dataset (or array) in the WSDL. That would let me use my function from, say, InfoPath.
Regards,
Ianier
|||Hi again,
FYI, I sent a bug report: http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?FeedbackId=9e1e9b79-079d-40eb-b3f8-441432a26cbc
Nevertheless, it's hard for me to believe that such a serious issue escaped Microsoft's testing, so I'm still hoping that I'm missing something obvious.
Regards,
Ianier
|||SQL Server's SOAP does not support table valued functions unfortunately. This is why it's not working. I found this out by talking to one of the testers. I cannot find where this is mentioned in the docs yet.|||Hello,
Thanks for the info.
That would be a major disapointment. This limitation is not documented and CREATE ENDPOINT reports no error, so this must be either a bug or an "undocumented odd behavior", which is the same.
IMO, not allowing table-value functions in a SOAP endpoint makes the WS feature extremely limited, if useful at all.
I'll come back to this group as soon as I get some feedback on my bug report.
Regards,
Ianier
|||
The SQL 2005 Books Online documentation does have a statement stating that Table Value Functions are not supported in Native XML Web Services. Under the "Guidelines and Limitations in Native XML Web Services" topic (ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/8907005f-7f9b-4f53-80b8-f42729caf86b.htm), there's a bullet point saying:
Table valued user-defined functions are not supported.|||Thank you Jimmy,In that case CREATE ENDPOINT should not succeed. This is definitely a bug.
Regards,
Ianier
|||
Hi Ianier,
Thanks for the feedback.
SQL 2005 actually allows the "CREATE ENDPOINT" query to be executed before any of the webmethods are created.
ie.
CREATE ENDPOINT sql
STATE = STARTED
AS HTTP(
PATH = '/sql',
AUTHENTICATION = (INTEGRATED ),
PORTS = ( CLEAR ),
CLEAR_PORT = 90,
SITE = 'mypc'
)
FOR SOAP (
WEBMETHOD 'TestFN'
(name='ReportingDB.dbo.TestFN', SCHEMA=STANDARD),
WSDL = DEFAULT,
SCHEMA = STANDARD,
DATABASE = 'ReportingDB',
NAMESPACE = 'http://tempUri.org/'
);
go
CREATE FUNCTION [dbo].[TestFN] ()
RETURNS
@.Table_Var TABLE (c1 int, c2 int)
AS
BEGIN
RETURN
END;
GO
In this scenario is would not be possible for the CREATE ENDPOINT query to verify what the webmethod is. You can argue that this should be a bug as well, but the current behavior provides a more flexible system. Suppose we were strict about requiring the webmethods to be created before the CREATE ENDPOINT query, what would happen if after the stored procedure or function was created, someone went and ALTER it or even DELETE it? Should the different endpoints to magically re-verify that the new version of the webmethod is still valid or even there?
The current mechanism allows SQL to verify at execution/run time that the methods are valid and the user has the proper permissions.
Hope that addresses some of your concerns.
Jimmy Wu [MSFT]
Hi Jimmy,
Thanks for the information.
Common sense tells me that if the function exists and is not of a supported type (i.e. a table-value one) then CREATE ENDPOINT should fail. After all, CREATE ENDPOINT fails, for example, when trying to bind a WEBMETHOD to a view because views are not supported.
If someone ALTERs or DELETEs the function afterwards in a way that is not compatible with the endpoint, either of the following should happen:
Option 1: give an error explaining that the WEBMETHOD should be modified first (i.e. there's a dependency).
Option 2: delete the WEBMETHOD automatically and give a warning to the user.
Regards,
Ianier
Bug? Legend values same color
two colors. 'Firebrick' for bad values and 'ForestGreen' for good. So I
have a simple global function to handle this. Sometimes though, for no
explainable reason, even though my bar chart has green and red series, the
legend shows red for each of the two existing series. How can this be? The
series colors on the chart should always by default correspond with the
colors rendered for the legend.
I will provide you any information required to get to the bottom of this.
For starters, I'm running Report Services SP2.Please someone help me on this one. I am fairly certain this is a bug in
reporting services but need help to confirm this.