Display reports accross domains

I have a simple report that shows the result of a SQL Server 2000 SPROC.
This works fine from any PC within MY DOMAIN. When a user in the same
company (Intranet) but on a different DOMAIN attempts to run the report the
can get as far as the report screen asking for the parameters but then they
are presented with that section of the screen as a "page cannot be displayed"
message.
When they open the report server URL they sign onto MY DOMAIN, no problems,
and can navigate the reports fine, right up to attempting to display a report.
I have attempted chjanging the .config files with a ExternalURL etc but
can't get anything working.
Any ideas?If the ReportServer web is set up to use Windows Auth, then any users in the
company using Reporting Services will have to be trusted users (ie, your
domains will have to be trusted if the users are coming from another domain,
etc...)
If this is not an option you may have to set Reporting Services up to use an
alternate authentication scheme (for example, Forms Authentication):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/ufairs.asp
"Ken Shabby" <Ken Shabby@.discussions.microsoft.com> wrote in message
news:6E0D1972-C805-4ABC-A7D0-9D16DE627E10@.microsoft.com...
>I have a simple report that shows the result of a SQL Server 2000 SPROC.
> This works fine from any PC within MY DOMAIN. When a user in the same
> company (Intranet) but on a different DOMAIN attempts to run the report
> the
> can get as far as the report screen asking for the parameters but then
> they
> are presented with that section of the screen as a "page cannot be
> displayed"
> message.
> When they open the report server URL they sign onto MY DOMAIN, no
> problems,
> and can navigate the reports fine, right up to attempting to display a
> report.
> I have attempted chjanging the .config files with a ExternalURL etc but
> can't get anything working.
> Any ideas?|||Their domain trusts our domain, but our domain does not trust their domain.
However, when they are presented with the Windows Auth log in screen for
reporting services they sign onto our domain using an account that i have set
up for them. In this case does this "trust" between domains matter' They
sign onto our domain no problems.
cheers
Ken
"Adrian M." wrote:
> If the ReportServer web is set up to use Windows Auth, then any users in the
> company using Reporting Services will have to be trusted users (ie, your
> domains will have to be trusted if the users are coming from another domain,
> etc...)
> If this is not an option you may have to set Reporting Services up to use an
> alternate authentication scheme (for example, Forms Authentication):
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/ufairs.asp
>
> "Ken Shabby" <Ken Shabby@.discussions.microsoft.com> wrote in message
> news:6E0D1972-C805-4ABC-A7D0-9D16DE627E10@.microsoft.com...
> >I have a simple report that shows the result of a SQL Server 2000 SPROC.
> >
> > This works fine from any PC within MY DOMAIN. When a user in the same
> > company (Intranet) but on a different DOMAIN attempts to run the report
> > the
> > can get as far as the report screen asking for the parameters but then
> > they
> > are presented with that section of the screen as a "page cannot be
> > displayed"
> > message.
> >
> > When they open the report server URL they sign onto MY DOMAIN, no
> > problems,
> > and can navigate the reports fine, right up to attempting to display a
> > report.
> >
> > I have attempted chjanging the .config files with a ExternalURL etc but
> > can't get anything working.
> >
> > Any ideas?
>
>

Display of date time inforamtion - some columns are NULL some are

Do the formatting where it belongs - on the client. In SQL you could use
CONVERT but then you loose the domain.
Another way would be to use sql_variant which retains the datatype for later
use, but that's just another complication that can be successfully avoided b
y
formatting the data on the client.
ML
http://milambda.blogspot.com/BCP doesn't have any formatting control logic built in.
Before making definitive statements you need to know more about what the
poster is trying to achieve.
I've done formatting lots of time in the SQL Server because thats been the
best place for that particular problem, for instance creating the output
file for a data feed, its very easy (a couple of lines of T-SQL) to create a
table and use BCP to output it to a file that can then be sent out to
another part of the company/supplier.
A statement like 'do the formatting where it belongs - on the client' is
meaningless in this instance.
Its more true to say 'Do the formatting where it makes sense and is most
efficient for the problem you are trying to solve'.
Sorry if the post sounds harsh, I'm a bit fed up with this do all formatting
on the client debarkle.
Tony.
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials
"ML" <ML@.discussions.microsoft.com> wrote in message
news:A73D446B-49C0-429A-B30C-EB11A035B5E7@.microsoft.com...
> Do the formatting where it belongs - on the client. In SQL you could use
> CONVERT but then you loose the domain.
> Another way would be to use sql_variant which retains the datatype for
> later
> use, but that's just another complication that can be successfully avoided
> by
> formatting the data on the client.
>
> ML
> --
> http://milambda.blogspot.com/