DROP TABLE failed

An overnight run failed, and I now regularly get the message:
Could not find row in sysindexes for database ID nn, object ID nnnnnnnnnn,
index ID -1. Run DBCC CHECKTABLE on sysindexes.
It appears that a DROP TABLE failed - the table does not show up in
Enterprise Manager, but a row for the table appears in sysobjects. DBCC
CHECKTABLE did not help.
How can I safely get out of this? Presumably it is not safe to delete the
row from sysobjects?
In future, would it help to put the DROP TABLE instruction within a
transaction?
Thanks.
Peter Hyssett
Yeah, that can happen, here is another post which clearly identifies the
problem and give a hint how to solve it:
http://groups.google.de/group/micros...5b5409616cfed4
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
"Peter Hyssett" <PeterHyssett@.discussions.microsoft.com> schrieb im
Newsbeitrag news:732EDDE9-15C5-42D4-9A81-F4A80E951320@.microsoft.com...
> An overnight run failed, and I now regularly get the message:
> Could not find row in sysindexes for database ID nn, object ID nnnnnnnnnn,
> index ID -1. Run DBCC CHECKTABLE on sysindexes.
> It appears that a DROP TABLE failed - the table does not show up in
> Enterprise Manager, but a row for the table appears in sysobjects. DBCC
> CHECKTABLE did not help.
> How can I safely get out of this? Presumably it is not safe to delete the
> row from sysobjects?
> In future, would it help to put the DROP TABLE instruction within a
> transaction?
> Thanks.
> --
> Peter Hyssett
sql

DROP TABLE failed

An overnight run failed, and I now regularly get the message:
Could not find row in sysindexes for database ID nn, object ID nnnnnnnnnn,
index ID -1. Run DBCC CHECKTABLE on sysindexes.
It appears that a DROP TABLE failed - the table does not show up in
Enterprise Manager, but a row for the table appears in sysobjects. DBCC
CHECKTABLE did not help.
How can I safely get out of this? Presumably it is not safe to delete the
row from sysobjects?
In future, would it help to put the DROP TABLE instruction within a
transaction?
Thanks.
--
Peter HyssettYeah, that can happen, here is another post which clearly identifies the
problem and give a hint how to solve it:
e97a7097d5e766ff/db5b5409616cfed4? q=%22Drop+Table%22+%22exists+in+sysobjec
ts%22&rn
um=3&hl=de#db5b5409616cfed4" target="_blank">http://groups.google.de/group/micro...b5b5409616cfed4
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"Peter Hyssett" <PeterHyssett@.discussions.microsoft.com> schrieb im
Newsbeitrag news:732EDDE9-15C5-42D4-9A81-F4A80E951320@.microsoft.com...
> An overnight run failed, and I now regularly get the message:
> Could not find row in sysindexes for database ID nn, object ID nnnnnnnnnn,
> index ID -1. Run DBCC CHECKTABLE on sysindexes.
> It appears that a DROP TABLE failed - the table does not show up in
> Enterprise Manager, but a row for the table appears in sysobjects. DBCC
> CHECKTABLE did not help.
> How can I safely get out of this? Presumably it is not safe to delete the
> row from sysobjects?
> In future, would it help to put the DROP TABLE instruction within a
> transaction?
> Thanks.
> --
> Peter Hyssett

DROP TABLE failed

An overnight run failed, and I now regularly get the message:
Could not find row in sysindexes for database ID nn, object ID nnnnnnnnnn,
index ID -1. Run DBCC CHECKTABLE on sysindexes.
It appears that a DROP TABLE failed - the table does not show up in
Enterprise Manager, but a row for the table appears in sysobjects. DBCC
CHECKTABLE did not help.
How can I safely get out of this? Presumably it is not safe to delete the
row from sysobjects?
In future, would it help to put the DROP TABLE instruction within a
transaction?
Thanks.
--
Peter HyssettYeah, that can happen, here is another post which clearly identifies the
problem and give a hint how to solve it:
http://groups.google.de/group/microsoft.public.sqlserver.server/browse_frm/thread/e97a7097d5e766ff/db5b5409616cfed4?q=%22Drop+Table%22+%22exists+in+sysobjects%22&rnum=3&hl=de#db5b5409616cfed4
HTH, Jens Suessmeyer.
--
http://www.sqlserver2005.de
--
"Peter Hyssett" <PeterHyssett@.discussions.microsoft.com> schrieb im
Newsbeitrag news:732EDDE9-15C5-42D4-9A81-F4A80E951320@.microsoft.com...
> An overnight run failed, and I now regularly get the message:
> Could not find row in sysindexes for database ID nn, object ID nnnnnnnnnn,
> index ID -1. Run DBCC CHECKTABLE on sysindexes.
> It appears that a DROP TABLE failed - the table does not show up in
> Enterprise Manager, but a row for the table appears in sysobjects. DBCC
> CHECKTABLE did not help.
> How can I safely get out of this? Presumably it is not safe to delete the
> row from sysobjects?
> In future, would it help to put the DROP TABLE instruction within a
> transaction?
> Thanks.
> --
> Peter Hyssett

Drillthrough row count is less than [Measures].[Sales Count] from cube

The reason that this is happening is somewhat attributed to the fact that I have 2 different breakouts (2 attributes in the same Customer dimension) of customer territories and security is only set at one of the territory types.

(Security was set at both, but I was having the fore mentioned issue, so I trimmed the restriction down to one territory for only one territory type - hoping that any customers under that one territory type would also show up under their corresponding territory type 2)

Thinking about the mdx/drillthrough results in more detail, I'm leaning toward the mdx results being wrong and the drillthrough being right.

Is there something I can do to fix this or is it a bug?

I wish I could give more detail, but it's tough.Adventure Works didn't seem to have a similar setup because customer.geography isn't related to sales territory.group.

If I run the following sql query on the source data, 3 of the type2 territories are returned:

select Territory2Name, count(*)

from dimCustomer

where Territory1Name = 'East'

group by Territory2Name

One of the Territory2Names is 'Section 2'.Now in here, there's only a count of 1 customer, yet when I look at the cube for Section 2 and [Sales Count], there's easily more than 1 customer composing the total and if I look at a sales dollars, it's the same thing.When I do a drillthrough, then it's correct - results are only for that one customer.

Any thoughts on this perplexing problem?

Does your security role have the Visual Totals option ticked?

If not it will be showing the total for the "All" member of the Territory1 attribute unless you are also explicitly filtering by a Territory1 member.

|||Both of the dimension data security attributes had visual totals checked.

What I ended up doing to solve this problem is only giving access to an area in territory type1 and did not specify any security on territory type 2. This was exceptable for my case - users just needed access to a sampling of the items in both territory types, but in other cases, a person might have to do more digging to get access to a specific area from both geographical types..

Drill-Down Context

I'm wanting to set the background color of a field. The field is part of a
drill-down row group (Office -> Transaction Type (visibility toggled by
Office) --> Field!TranCount.Value).
I would like to set the background color based on 2 conditions:
1) Field!x.Value (which I know) - this works currently
2) The context of the TranCount field
By context I mean...
If the drilldown is "open" or "closed".
Since the expression language in SRS is, apparently, very limited (and not
very well documented) I'm assuming that I'll have to live with Just setting
the background color based on the known field values.. but I can always ask!!!
TIADetermining the state of the drilldown toggle is not supported.
Bruce Johnson [MSFT]
Microsoft SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Glenn" <Glenn@.discussions.microsoft.com> wrote in message
news:82E55B4E-8153-4456-B0B9-9F45AE8AE797@.microsoft.com...
> I'm wanting to set the background color of a field. The field is part of a
> drill-down row group (Office -> Transaction Type (visibility toggled by
> Office) --> Field!TranCount.Value).
> I would like to set the background color based on 2 conditions:
> 1) Field!x.Value (which I know) - this works currently
> 2) The context of the TranCount field
> By context I mean...
> If the drilldown is "open" or "closed".
> Since the expression language in SRS is, apparently, very limited (and not
> very well documented) I'm assuming that I'll have to live with Just
> setting
> the background color based on the known field values.. but I can always
> ask!!!
> TIA