Intermittent issue with outer joins on subqueries

Hello, we are running into an issue which seems to be a bug in the way
MSSQL joins on subqueries. The below query is run daily by a scheduled
task and usually runs correctly. About once a week the query produces
a resultset that makes it appear that the outer join on the subquery
(alias: POINFO) was changed to an inner join. The resultset has only a
percentage of the records it should have as a result. Are there any
know issues with MSSQL 2000 SP4 that are know to cause this. BTW, the
problem happens on a Win2000 server. Thanks.
SELECT *
FROM rc.dbo.LineItems LI
INNER JOIN rc.dbo.orders O
ON O.guidPK = LI.orderguidPK
INNER JOIN decode DECODE
ON O.status = DECODE.status
INNER JOIN products P
ON LI.productPK = P.PK
/* The below join periodically seems to become an inner join
*/
LEFT OUTER JOIN (SELECT PO.OrderNumber, FP.ProductNumber
from purchase_orders PO
INNER JOIN purchase_orders_lines POL
ON PO.PK = POL.purchaseorderPK
INNER JOIN fulfillment_products FP
ON POL.intProductID = FP.PK AND PO.supplierPK = FP.supplierPK
INNER JOIN I18NManufacturer MAN
ON FP.manPK = MAN.PK
INNER JOIN suppliers S
ON FP.supplierPK = SM.PK
WHERE PO.status <>9 AND MAN.locale = 1041) AS POINFO
ON O.order_number = POINFO.order_number AND LI.productPK =
POINFO.productPK
WHERE O.order_type <> 1 and O.active=1
and O.status between 2 and 32
Can you capture the plan when the bad result happens, and compare it to the
normal plan?
(In other words, does it happen frequently enough that if you tried, you
could reproduce the problem in Query Analyzer?)
"Jesse Hogan" <JesseHogan0@.gmail.com> wrote in message
news:049ac85e-1cde-4fd9-8755-0b03494302d2@.1g2000hsl.googlegroups.com...
> Hello, we are running into an issue which seems to be a bug in the way
> MSSQL joins on subqueries. The below query is run daily by a scheduled
> task and usually runs correctly. About once a week the query produces
> a resultset that makes it appear that the outer join on the subquery
> (alias: POINFO) was changed to an inner join. The resultset has only a
> percentage of the records it should have as a result. Are there any
> know issues with MSSQL 2000 SP4 that are know to cause this. BTW, the
> problem happens on a Win2000 server. Thanks.
> SELECT *
> FROM rc.dbo.LineItems LI
> INNER JOIN rc.dbo.orders O
> ON O.guidPK = LI.orderguidPK
> INNER JOIN decode DECODE
> ON O.status = DECODE.status
> INNER JOIN products P
> ON LI.productPK = P.PK
> /* The below join periodically seems to become an inner join
> */
> LEFT OUTER JOIN (SELECT PO.OrderNumber, FP.ProductNumber
> from purchase_orders PO
> INNER JOIN purchase_orders_lines POL
> ON PO.PK = POL.purchaseorderPK
> INNER JOIN fulfillment_products FP
> ON POL.intProductID = FP.PK AND PO.supplierPK = FP.supplierPK
> INNER JOIN I18NManufacturer MAN
> ON FP.manPK = MAN.PK
> INNER JOIN suppliers S
> ON FP.supplierPK = SM.PK
> WHERE PO.status <>9 AND MAN.locale = 1041) AS POINFO
> ON O.order_number = POINFO.order_number AND LI.productPK =
> POINFO.productPK
> WHERE O.order_type <> 1 and O.active=1
> and O.status between 2 and 32
|||I would be much more likely to think the WHERE clause is limiting the rows
'unexpectedly'. Perhaps you should set up an audit trail whereby you store
the COUNT(*) of the entire SELECT as well as the COUNT(*) for the SELECT
without the join to POINFO by itself into a table each time this process is
run (with enough identifying information added to ensure you can pinpoint
the rows for each run). This will help you see if you are affecting fewer
rows with the main query simply because of the WHERE clause or is the LOJ
magically translating into an INNER JOIN. That will give you definitive
evidence to take to Microsoft if it is a bug too (which I will definitely
admit isn't out of the question). :-)
Doing a quick check of post-SP4 hotfixes, see if this one applies
http://support.microsoft.com/kb/892310/
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Jesse Hogan" <JesseHogan0@.gmail.com> wrote in message
news:049ac85e-1cde-4fd9-8755-0b03494302d2@.1g2000hsl.googlegroups.com...
> Hello, we are running into an issue which seems to be a bug in the way
> MSSQL joins on subqueries. The below query is run daily by a scheduled
> task and usually runs correctly. About once a week the query produces
> a resultset that makes it appear that the outer join on the subquery
> (alias: POINFO) was changed to an inner join. The resultset has only a
> percentage of the records it should have as a result. Are there any
> know issues with MSSQL 2000 SP4 that are know to cause this. BTW, the
> problem happens on a Win2000 server. Thanks.
> SELECT *
> FROM rc.dbo.LineItems LI
> INNER JOIN rc.dbo.orders O
> ON O.guidPK = LI.orderguidPK
> INNER JOIN decode DECODE
> ON O.status = DECODE.status
> INNER JOIN products P
> ON LI.productPK = P.PK
> /* The below join periodically seems to become an inner join
> */
> LEFT OUTER JOIN (SELECT PO.OrderNumber, FP.ProductNumber
> from purchase_orders PO
> INNER JOIN purchase_orders_lines POL
> ON PO.PK = POL.purchaseorderPK
> INNER JOIN fulfillment_products FP
> ON POL.intProductID = FP.PK AND PO.supplierPK = FP.supplierPK
> INNER JOIN I18NManufacturer MAN
> ON FP.manPK = MAN.PK
> INNER JOIN suppliers S
> ON FP.supplierPK = SM.PK
> WHERE PO.status <>9 AND MAN.locale = 1041) AS POINFO
> ON O.order_number = POINFO.order_number AND LI.productPK =
> POINFO.productPK
> WHERE O.order_type <> 1 and O.active=1
> and O.status between 2 and 32

Intermittent issue with outer joins on subqueries

Hello, we are running into an issue which seems to be a bug in the way
MSSQL joins on subqueries. The below query is run daily by a scheduled
task and usually runs correctly. About once a week the query produces
a resultset that makes it appear that the outer join on the subquery
(alias: POINFO) was changed to an inner join. The resultset has only a
percentage of the records it should have as a result. Are there any
know issues with MSSQL 2000 SP4 that are know to cause this. BTW, the
problem happens on a Win2000 server. Thanks.
SELECT *
FROM rc.dbo.LineItems LI
INNER JOIN rc.dbo.orders O
ON O.guidPK = LI.orderguidPK
INNER JOIN decode DECODE
ON O.status = DECODE.status
INNER JOIN products P
ON LI.productPK = P.PK
/* The below join periodically seems to become an inner join
*/
LEFT OUTER JOIN (SELECT PO.OrderNumber, FP.ProductNumber
from purchase_orders PO
INNER JOIN purchase_orders_lines POL
ON PO.PK = POL.purchaseorderPK
INNER JOIN fulfillment_products FP
ON POL.intProductID = FP.PK AND PO.supplierPK = FP.supplierPK
INNER JOIN I18NManufacturer MAN
ON FP.manPK = MAN.PK
INNER JOIN suppliers S
ON FP.supplierPK = SM.PK
WHERE PO.status <>9 AND MAN.locale = 1041) AS POINFO
ON O.order_number = POINFO.order_number AND LI.productPK = POINFO.productPK
WHERE O.order_type <> 1 and O.active=1
and O.status between 2 and 32Can you capture the plan when the bad result happens, and compare it to the
normal plan?
(In other words, does it happen frequently enough that if you tried, you
could reproduce the problem in Query Analyzer?)
"Jesse Hogan" <JesseHogan0@.gmail.com> wrote in message
news:049ac85e-1cde-4fd9-8755-0b03494302d2@.1g2000hsl.googlegroups.com...
> Hello, we are running into an issue which seems to be a bug in the way
> MSSQL joins on subqueries. The below query is run daily by a scheduled
> task and usually runs correctly. About once a week the query produces
> a resultset that makes it appear that the outer join on the subquery
> (alias: POINFO) was changed to an inner join. The resultset has only a
> percentage of the records it should have as a result. Are there any
> know issues with MSSQL 2000 SP4 that are know to cause this. BTW, the
> problem happens on a Win2000 server. Thanks.
> SELECT *
> FROM rc.dbo.LineItems LI
> INNER JOIN rc.dbo.orders O
> ON O.guidPK = LI.orderguidPK
> INNER JOIN decode DECODE
> ON O.status = DECODE.status
> INNER JOIN products P
> ON LI.productPK = P.PK
> /* The below join periodically seems to become an inner join
> */
> LEFT OUTER JOIN (SELECT PO.OrderNumber, FP.ProductNumber
> from purchase_orders PO
> INNER JOIN purchase_orders_lines POL
> ON PO.PK = POL.purchaseorderPK
> INNER JOIN fulfillment_products FP
> ON POL.intProductID = FP.PK AND PO.supplierPK = FP.supplierPK
> INNER JOIN I18NManufacturer MAN
> ON FP.manPK = MAN.PK
> INNER JOIN suppliers S
> ON FP.supplierPK = SM.PK
> WHERE PO.status <>9 AND MAN.locale = 1041) AS POINFO
> ON O.order_number = POINFO.order_number AND LI.productPK => POINFO.productPK
> WHERE O.order_type <> 1 and O.active=1
> and O.status between 2 and 32|||I would be much more likely to think the WHERE clause is limiting the rows
'unexpectedly'. Perhaps you should set up an audit trail whereby you store
the COUNT(*) of the entire SELECT as well as the COUNT(*) for the SELECT
without the join to POINFO by itself into a table each time this process is
run (with enough identifying information added to ensure you can pinpoint
the rows for each run). This will help you see if you are affecting fewer
rows with the main query simply because of the WHERE clause or is the LOJ
magically translating into an INNER JOIN. That will give you definitive
evidence to take to Microsoft if it is a bug too (which I will definitely
admit isn't out of the question). :-)
Doing a quick check of post-SP4 hotfixes, see if this one applies
http://support.microsoft.com/kb/892310/
--
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Jesse Hogan" <JesseHogan0@.gmail.com> wrote in message
news:049ac85e-1cde-4fd9-8755-0b03494302d2@.1g2000hsl.googlegroups.com...
> Hello, we are running into an issue which seems to be a bug in the way
> MSSQL joins on subqueries. The below query is run daily by a scheduled
> task and usually runs correctly. About once a week the query produces
> a resultset that makes it appear that the outer join on the subquery
> (alias: POINFO) was changed to an inner join. The resultset has only a
> percentage of the records it should have as a result. Are there any
> know issues with MSSQL 2000 SP4 that are know to cause this. BTW, the
> problem happens on a Win2000 server. Thanks.
> SELECT *
> FROM rc.dbo.LineItems LI
> INNER JOIN rc.dbo.orders O
> ON O.guidPK = LI.orderguidPK
> INNER JOIN decode DECODE
> ON O.status = DECODE.status
> INNER JOIN products P
> ON LI.productPK = P.PK
> /* The below join periodically seems to become an inner join
> */
> LEFT OUTER JOIN (SELECT PO.OrderNumber, FP.ProductNumber
> from purchase_orders PO
> INNER JOIN purchase_orders_lines POL
> ON PO.PK = POL.purchaseorderPK
> INNER JOIN fulfillment_products FP
> ON POL.intProductID = FP.PK AND PO.supplierPK = FP.supplierPK
> INNER JOIN I18NManufacturer MAN
> ON FP.manPK = MAN.PK
> INNER JOIN suppliers S
> ON FP.supplierPK = SM.PK
> WHERE PO.status <>9 AND MAN.locale = 1041) AS POINFO
> ON O.order_number = POINFO.order_number AND LI.productPK => POINFO.productPK
> WHERE O.order_type <> 1 and O.active=1
> and O.status between 2 and 32

Intermittent field display

This is either a bug, or I am crazy.

I have developed a report that pulls its data from an SSAS cube. The report is grouped on Fields!FacilityName. On each "page" of the report, I have information for the displayed facility.

At the top of each page in my report I have a textbox whose value is =Fields!FacilityName. Further down on the report I have another text box whose value is set exactly the same. When I preview the report, I always have a value in the upper box, but only sometimes have a value in the lower box. If I change the value in the lower box to just a text string, it will always display, but when I put in the actual field reference it does not. It always doesn't display for the same facility names. Remember, the upper textbox on the form always displays 100% of the time.

I have a Dundas chart in the middle of the page on the report between these textboxes, but another field that pulls parameters and even a matrix all render correctly below that chart.

They both have the same parent according to the properties. I have even copied and pasted the working textbox further down the screen, with no improvement. When I changed the value of the textbox to "=cstr(len(Fields!FacilityName))", on the pages when it wants to be blank, it reads 0, and on other pages it shows a larger number. But the other textbox on the screen will always properly show the FacilityName.

I have also tried changing the name of the textbox, settings output to YES instead of Auto. If I slide the non-working textbox up to the top of the page and the working textbox down to the bottom area of the page, the bevavior switches.

Does anybody know of rendering issues with textboxes showing the same infomation?

Are you running at least SSRS2005 SP1 (on the server and for BI Dev.Studio)?

-- Robert

|||My server is running Microsoft SQL Server Reporting Services Version 9.00.2047.00, and I am using VS 2005 with the most recent service pack on my development PC. Both exibit the behavior I describe.
Could it be something odd in the XML of the report that I just cannot see in the IDE?
|||We are running 9.00.2047.00 on the server, and my VS 2005 is up to date. Maybe there is something buried in the XML of the RDL that I just cannot see in the IDE that is causing the problem.|||I also have a ticket in with Dundas since when I remove the chart off the report, the textbox renders correctly. Perhaps the chart is breaking the recordset in some way.

Interesting Problem/Bug with Logos in the page header

Scenario:

I have a report with a logo in the page header.

This report has 2 parameters: 1) Date 2) Boolean to Show/Hide detail.

When I put in the date and show the report, everything is fine. If I then change the boolean parameter to show or hide the detail, the logo file cannot be found (Displays a red X)

If I export the report like this, the red X is rendered in the export. The logo is not there.

Has anyone else experienced this issue?

Anyone know how to resolve it?

Thanks!

BobP

This is a known bug. The fix will be included in the next release.

Interesting CASE behavior -- bug?

(SQL Server 2000, SP3a)
Hello all!
I had a situation where I was getting some extraneous spaces in some string
building, and
it took me a while to figure it out. I think I can appreciate *why* it's do
ing this, but
I wish it weren't.
Consider the following:
declare @.CrLf nchar(2) select @.CrLf = nchar(13) + nchar(10)
declare @.String nvarchar(255) select @.String = N''
select @.String = @.String + case when (len(@.String) != 0) then @.CrLf + @.CrLf
else N'' end +
N'Test'
print N'"' + @.String + N'"'
print [master].[dbo].& #91;fn_varbintohexstr](convert(varbinary
(16),
@.String))
The output is:
" Test"
0x20002000200020005400650073007400
It feels like, for some reason, the CASE is evaluating both "sides" of the r
esultant
expression, and determining that it can be coerced to a NCHAR(2). However,
somewhere
along the lines, it gets confused and is introducing 2 bytes for every NCHAR
-- sort of
like accidentally making it a CHAR(4) that then gets promoted to a NCHAR(4)
(as per the
NULL bytes in every other character).
If I change the definition of @.CrLf to be a NVARCHAR(2), then everything wor
ks as
expected.
It's very odd, and certainly smells like a bug to me.
Thoughts?Hi John,
This behaviour isn't a bug. CASE is an expression that returns one datatype
only, and the datatype it returns is determined by looking at the datatypes
of all the possible results of the expression, and then choosing the
appropriate datatype according to the datatype precedence. So what happens
is that your CASE can either return a zero length NCHAR literal (N''), or a
NCHAR(4) (@.CrLf + @.CrLf) so the return type of your CASE expression will be
NCHAR(4), as this has a higher precedence.
--
Jacco Schalkwijk
SQL Server MVP
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:OM4e%23b6$DHA.3048@.tk2msftngp13.phx.gbl...
> (SQL Server 2000, SP3a)
> Hello all!
> I had a situation where I was getting some extraneous spaces in some
string building, and
> it took me a while to figure it out. I think I can appreciate *why* it's
doing this, but
> I wish it weren't.
> Consider the following:
>
> declare @.CrLf nchar(2) select @.CrLf = nchar(13) + nchar(10)
> declare @.String nvarchar(255) select @.String = N''
> select @.String = @.String + case when (len(@.String) != 0) then @.CrLf +
@.CrLf else N'' end +
> N'Test'
> print N'"' + @.String + N'"'
> print [master].[dbo].& #91;fn_varbintohexstr](convert(varbinary
(16)
, @.String))
>
> The output is:
>
> " Test"
> 0x20002000200020005400650073007400
>
> It feels like, for some reason, the CASE is evaluating both "sides" of the
resultant
> expression, and determining that it can be coerced to a NCHAR(2).
However, somewhere
> along the lines, it gets confused and is introducing 2 bytes for every
NCHAR -- sort of
> like accidentally making it a CHAR(4) that then gets promoted to a
NCHAR(4) (as per the
> NULL bytes in every other character).
> If I change the definition of @.CrLf to be a NVARCHAR(2), then everything
works as
> expected.
> It's very odd, and certainly smells like a bug to me.
> Thoughts?
>|||Ah, yes...I think I grok that -- I think that I forgot that I had *two* @.CrL
fs in my first
expression (hence the doubling).
Thanks for your help!
John Peterson
"Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
news:uWhzb36$DHA.3352@.TK2MSFTNGP09.phx.gbl...
> Hi John,
> This behaviour isn't a bug. CASE is an expression that returns one datatyp
e
> only, and the datatype it returns is determined by looking at the datatype
s
> of all the possible results of the expression, and then choosing the
> appropriate datatype according to the datatype precedence. So what happens
> is that your CASE can either return a zero length NCHAR literal (N''), or
a
> NCHAR(4) (@.CrLf + @.CrLf) so the return type of your CASE expression will b
e
> NCHAR(4), as this has a higher precedence.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:OM4e%23b6$DHA.3048@.tk2msftngp13.phx.gbl...
> string building, and
> doing this, but
> @.CrLf else N'' end +
> resultant
> However, somewhere
> NCHAR -- sort of
> NCHAR(4) (as per the
> works as
>

Interesting CASE behavior -- bug?

(SQL Server 2000, SP3a)
Hello all!
I had a situation where I was getting some extraneous spaces in some string building, and
it took me a while to figure it out. I think I can appreciate *why* it's doing this, but
I wish it weren't.
Consider the following:
declare @.CrLf nchar(2) select @.CrLf = nchar(13) + nchar(10)
declare @.String nvarchar(255) select @.String = N''
select @.String = @.String + case when (len(@.String) != 0) then @.CrLf + @.CrLf else N'' end +
N'Test'
print N'"' + @.String + N'"'
print [master].[dbo].[fn_varbintohexstr](convert(varbinary(16), @.String))
The output is:
" Test"
0x20002000200020005400650073007400
It feels like, for some reason, the CASE is evaluating both "sides" of the resultant
expression, and determining that it can be coerced to a NCHAR(2). However, somewhere
along the lines, it gets confused and is introducing 2 bytes for every NCHAR -- sort of
like accidentally making it a CHAR(4) that then gets promoted to a NCHAR(4) (as per the
NULL bytes in every other character).
If I change the definition of @.CrLf to be a NVARCHAR(2), then everything works as
expected.
It's very odd, and certainly smells like a bug to me.
Thoughts?Hi John,
This behaviour isn't a bug. CASE is an expression that returns one datatype
only, and the datatype it returns is determined by looking at the datatypes
of all the possible results of the expression, and then choosing the
appropriate datatype according to the datatype precedence. So what happens
is that your CASE can either return a zero length NCHAR literal (N''), or a
NCHAR(4) (@.CrLf + @.CrLf) so the return type of your CASE expression will be
NCHAR(4), as this has a higher precedence.
--
Jacco Schalkwijk
SQL Server MVP
"John Peterson" <j0hnp@.comcast.net> wrote in message
news:OM4e%23b6$DHA.3048@.tk2msftngp13.phx.gbl...
> (SQL Server 2000, SP3a)
> Hello all!
> I had a situation where I was getting some extraneous spaces in some
string building, and
> it took me a while to figure it out. I think I can appreciate *why* it's
doing this, but
> I wish it weren't.
> Consider the following:
>
> declare @.CrLf nchar(2) select @.CrLf = nchar(13) + nchar(10)
> declare @.String nvarchar(255) select @.String = N''
> select @.String = @.String + case when (len(@.String) != 0) then @.CrLf +
@.CrLf else N'' end +
> N'Test'
> print N'"' + @.String + N'"'
> print [master].[dbo].[fn_varbintohexstr](convert(varbinary(16), @.String))
>
> The output is:
>
> " Test"
> 0x20002000200020005400650073007400
>
> It feels like, for some reason, the CASE is evaluating both "sides" of the
resultant
> expression, and determining that it can be coerced to a NCHAR(2).
However, somewhere
> along the lines, it gets confused and is introducing 2 bytes for every
NCHAR -- sort of
> like accidentally making it a CHAR(4) that then gets promoted to a
NCHAR(4) (as per the
> NULL bytes in every other character).
> If I change the definition of @.CrLf to be a NVARCHAR(2), then everything
works as
> expected.
> It's very odd, and certainly smells like a bug to me.
> Thoughts?
>|||Ah, yes...I think I grok that -- I think that I forgot that I had *two* @.CrLfs in my first
expression (hence the doubling).
Thanks for your help!
John Peterson
"Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
news:uWhzb36$DHA.3352@.TK2MSFTNGP09.phx.gbl...
> Hi John,
> This behaviour isn't a bug. CASE is an expression that returns one datatype
> only, and the datatype it returns is determined by looking at the datatypes
> of all the possible results of the expression, and then choosing the
> appropriate datatype according to the datatype precedence. So what happens
> is that your CASE can either return a zero length NCHAR literal (N''), or a
> NCHAR(4) (@.CrLf + @.CrLf) so the return type of your CASE expression will be
> NCHAR(4), as this has a higher precedence.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "John Peterson" <j0hnp@.comcast.net> wrote in message
> news:OM4e%23b6$DHA.3048@.tk2msftngp13.phx.gbl...
> > (SQL Server 2000, SP3a)
> >
> > Hello all!
> >
> > I had a situation where I was getting some extraneous spaces in some
> string building, and
> > it took me a while to figure it out. I think I can appreciate *why* it's
> doing this, but
> > I wish it weren't.
> >
> > Consider the following:
> >
> >
> > declare @.CrLf nchar(2) select @.CrLf = nchar(13) + nchar(10)
> > declare @.String nvarchar(255) select @.String = N''
> >
> > select @.String = @.String + case when (len(@.String) != 0) then @.CrLf +
> @.CrLf else N'' end +
> > N'Test'
> > print N'"' + @.String + N'"'
> > print [master].[dbo].[fn_varbintohexstr](convert(varbinary(16), @.String))
> >
> >
> > The output is:
> >
> >
> > " Test"
> > 0x20002000200020005400650073007400
> >
> >
> > It feels like, for some reason, the CASE is evaluating both "sides" of the
> resultant
> > expression, and determining that it can be coerced to a NCHAR(2).
> However, somewhere
> > along the lines, it gets confused and is introducing 2 bytes for every
> NCHAR -- sort of
> > like accidentally making it a CHAR(4) that then gets promoted to a
> NCHAR(4) (as per the
> > NULL bytes in every other character).
> >
> > If I change the definition of @.CrLf to be a NVARCHAR(2), then everything
> works as
> > expected.
> >
> > It's very odd, and certainly smells like a bug to me.
> >
> > Thoughts?
> >
> >
>

Interactive Sort (problem/bug)

Hi

Header image (setup as external) disappear when interactive sort is used (interactive sort is set in the body of the report), works fine if the image is embedded.

any help is appreciated.

Thank you

Veneto

This is a known issue. The fix is available in a hotfix for RS 2005 SP1, and will also be included in the next service pack.|||Thank you for replying.

Interactive drill-through bug

Hi,
I've got a report with 3 columns, each one contains a "Y" which links
to a different report. Two of the columns work 100% but for some reason
the 3rd column won't link through once the report has been deployed.
All 3 links work fine when I'm using the "preview" tab in VS.NET
I've tried through report manager & our custom web application and I
get the same problem - It's very weird as I'm not doing anything fancy
and like I said it works fine through VS.NET
currently running SP2.
Any help would be much appreciated.
Thanks,
David SandellDavid,
What error message are you getting?
This sort of problem often indicates a permission issue or a pathname
issue.
Chris
sandelld wrote:
> Hi,
> I've got a report with 3 columns, each one contains a "Y" which links
> to a different report. Two of the columns work 100% but for some
> reason the 3rd column won't link through once the report has been
> deployed. All 3 links work fine when I'm using the "preview" tab in
> VS.NET
> I've tried through report manager & our custom web application and I
> get the same problem - It's very weird as I'm not doing anything fancy
> and like I said it works fine through VS.NET
> currently running SP2.
> Any help would be much appreciated.
> Thanks,
> David Sandell