Authentication hell report builder RS 2005

I started playing with VS 2005 and SQL 2005 to try to get ready to migrate
some of our apps. I ended up in authentication hell. I am trying to play
with it on my XP machine before I do some real world stuff.
I first tried the new report builder and was able to generate a data model
and build a report. But when I try to run it I get a logon failure with bad
user name and password.
So I thought I would fall back and create a rdl from VS and publish that
(i've done this hundreds of times in VS 2003). I am able to build the
report...preview it in VS. But I am unable to view in my browser
http://localhost...Again logon failure.
I checked IIS settings (I thought we did not need to do this in VS 2005? Ya
right). And it is using Windows Auth. but it is not identifying me correctly?
I tried enabling anonymous and setting the the anonymous account=to me but
that did not work either?
What am I missing?
Bill
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-reporting/200512/1I am also having this problem. I am able to create a connection, generate a
data model and am attempting to use the Report Builder application to design
a report. I am able to design the report, save it to the server but when I
use the "Run Report" from the Report Builder I receive:
"The permissions granted to user '<domain user>' are insufficient for
performing this operation. (rsAccessDenied)"
I am able to access the report from the RS web interface and run the report
without errors so it seems to be some sort of action that the "Run Report"
feature in the Report Builder client is making.
If any one has any suggestions please let me know as I cannot find any
solutions on line. Thanks.
"William N via SQLMonster.com" wrote:
> I started playing with VS 2005 and SQL 2005 to try to get ready to migrate
> some of our apps. I ended up in authentication hell. I am trying to play
> with it on my XP machine before I do some real world stuff.
> I first tried the new report builder and was able to generate a data model
> and build a report. But when I try to run it I get a logon failure with bad
> user name and password.
> So I thought I would fall back and create a rdl from VS and publish that
> (i've done this hundreds of times in VS 2003). I am able to build the
> report...preview it in VS. But I am unable to view in my browser
> http://localhost...Again logon failure.
> I checked IIS settings (I thought we did not need to do this in VS 2005? Ya
> right). And it is using Windows Auth. but it is not identifying me correctly?
> I tried enabling anonymous and setting the the anonymous account=to me but
> that did not work either?
> What am I missing?
> Bill
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-reporting/200512/1
>

Audit and Error Log Tables

I've seen it done before that tables that contain Audit logs and Error data
are sometimes placed in a different database.
As some apps log user actions in quite a bit of detail these tables can get
quite big and make the database grow quite large.
I just wondered what peoples thoughts on this approach are. Other than the
size of the database does have a couple of massive tables have any impact on
the performance of the database.
TIA
MattC> I just wondered what peoples thoughts on this approach are. Other than
> the size of the database does have a couple of massive tables have any
> impact on the performance of the database.
Large audit tables won't negatively affect performance. You'll incur the
write overhead regardless of the database in which the tables reside.
The main issue with large tables is manageability. Audit tables are
particularly good candidates for SQL 2005 partitioning because they are
often large and can often be partitioned by date.
Hope this helps.
Dan Guzman
SQL Server MVP
"MattC" <m@.m.com> wrote in message
news:OVTeThWkHHA.4800@.TK2MSFTNGP02.phx.gbl...
> I've seen it done before that tables that contain Audit logs and Error
> data are sometimes placed in a different database.
> As some apps log user actions in quite a bit of detail these tables can
> get quite big and make the database grow quite large.
> I just wondered what peoples thoughts on this approach are. Other than
> the size of the database does have a couple of massive tables have any
> impact on the performance of the database.
> TIA
> MattC
>|||Hi,
We have a database that archives modified records to a separate database.
One drawback of that design is security management. Every time a new user
or domain group is granted write access to the main database, I have to
remember to add the login to the archive database as well.
Daniel Jameson
.............................
.
You don't have to agree with an artist's opinion
to appreciate the art with which he expresses it.
"MattC" <m@.m.com> wrote in message
news:OVTeThWkHHA.4800@.TK2MSFTNGP02.phx.gbl...
> I've seen it done before that tables that contain Audit logs and Error
> data are sometimes placed in a different database.
> As some apps log user actions in quite a bit of detail these tables can
> get quite big and make the database grow quite large.
> I just wondered what peoples thoughts on this approach are. Other than
> the size of the database does have a couple of massive tables have any
> impact on the performance of the database.
> TIA
> MattC
>

Audit and Error Log Tables

I've seen it done before that tables that contain Audit logs and Error data
are sometimes placed in a different database.
As some apps log user actions in quite a bit of detail these tables can get
quite big and make the database grow quite large.
I just wondered what peoples thoughts on this approach are. Other than the
size of the database does have a couple of massive tables have any impact on
the performance of the database.
TIA
MattC> I just wondered what peoples thoughts on this approach are. Other than
> the size of the database does have a couple of massive tables have any
> impact on the performance of the database.
Large audit tables won't negatively affect performance. You'll incur the
write overhead regardless of the database in which the tables reside.
The main issue with large tables is manageability. Audit tables are
particularly good candidates for SQL 2005 partitioning because they are
often large and can often be partitioned by date.
Hope this helps.
Dan Guzman
SQL Server MVP
"MattC" <m@.m.com> wrote in message
news:OVTeThWkHHA.4800@.TK2MSFTNGP02.phx.gbl...
> I've seen it done before that tables that contain Audit logs and Error
> data are sometimes placed in a different database.
> As some apps log user actions in quite a bit of detail these tables can
> get quite big and make the database grow quite large.
> I just wondered what peoples thoughts on this approach are. Other than
> the size of the database does have a couple of massive tables have any
> impact on the performance of the database.
> TIA
> MattC
>|||Hi,
We have a database that archives modified records to a separate database.
One drawback of that design is security management. Every time a new user
or domain group is granted write access to the main database, I have to
remember to add the login to the archive database as well.
--
Daniel Jameson
·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·.·
You don't have to agree with an artist's opinion
to appreciate the art with which he expresses it.
"MattC" <m@.m.com> wrote in message
news:OVTeThWkHHA.4800@.TK2MSFTNGP02.phx.gbl...
> I've seen it done before that tables that contain Audit logs and Error
> data are sometimes placed in a different database.
> As some apps log user actions in quite a bit of detail these tables can
> get quite big and make the database grow quite large.
> I just wondered what peoples thoughts on this approach are. Other than
> the size of the database does have a couple of massive tables have any
> impact on the performance of the database.
> TIA
> MattC
>