Hi...
Please, someone knows what is this message:
OLAP Services Processing Task error '8004ffff'
Microsoft SQL Server OLAP Services must be installed on this computer and the user must be an OLAP Administrator in order to create an OLAP processing task.
The OLAP Services are OK, and the User is a OLAP Admin....
Thanks
David.HOw about the SP level on the SQL and OS?
Try to RESTART the OLAP services and see.|||Originally posted by Satya
HOw about the SP level on the SQL and OS?
Try to RESTART the OLAP services and see.
I tried, but don't work. The problem persists.
(Sorry about my english, but I'm not American)|||May refer this OLAP resources (http://groups.msn.com/MicrosoftOLAPServicesUsersCommunity/_homepage.msnw?pgmarket=en-us) for any help.
If nothing found then the only option is to reinstall the OLAP services as specified.
Showing posts with label knows. Show all posts
Showing posts with label knows. Show all posts
Friday, March 30, 2012
Wednesday, March 21, 2012
Odd problem with Profiler
I wonder if anyone here knows what the problem is.
On one server that I administer, when running a Profiler trace (either
through the GUI or directly using the stored procs) the â'Readsâ' column always
returns 0 no matter what event is being monitored.
The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
Thanks in advance,
AntoIrishAnto wrote:
> I wonder if anyone here knows what the problem is.
> On one server that I administer, when running a Profiler trace (either
> through the GUI or directly using the stored procs) the â'Readsâ'
> column always returns 0 no matter what event is being monitored.
> The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
> Thanks in advance,
> Anto
I saw this reported once on a customer who used EMC disks and broke a
cluster to make two stand-alone installs of SQL Server. That's when the
read statistics were no longer were captured. I can't say I remember
what the solution was.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com|||"David Gugick" wrote:
> IrishAnto wrote:
> > I wonder if anyone here knows what the problem is.
> >
> > On one server that I administer, when running a Profiler trace (either
> > through the GUI or directly using the stored procs) the â'Readsâ'
> > column always returns 0 no matter what event is being monitored.
> >
> > The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
> >
> > Thanks in advance,
> >
> > Anto
> I saw this reported once on a customer who used EMC disks and broke a
> cluster to make two stand-alone installs of SQL Server. That's when the
> read statistics were no longer were captured. I can't say I remember
> what the solution was.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
The server in question was never part of a cluster. As far as I'm aware
profiler used to return values in the reads column, but no longer.
I've seen other message boards with the same problem posted, but with no
answers. I was hoping someone at Microsoft might know of a solution.
Anto|||IrishAnto wrote:
> The server in question was never part of a cluster. As far as I'm
> aware profiler used to return values in the reads column, but no
> longer. I've seen other message boards with the same problem posted,
> but with no answers. I was hoping someone at Microsoft might know of
> a solution.
>
This is likely not a Profiler issue, but a SQL Trace API one on the
server. I assume the problem occurs from all clients, including the
server itself.
I might consider opening a support case with Microsoft... and then
sharing the solution with the rest of us :-)
In any case, I assume you are running SP3a or SP4 on the server. Is that
correct?
David Gugick
Quest Software
www.imceda.com
www.quest.com|||"David Gugick" wrote:
> IrishAnto wrote:
> > The server in question was never part of a cluster. As far as I'm
> > aware profiler used to return values in the reads column, but no
> > longer. I've seen other message boards with the same problem posted,
> > but with no answers. I was hoping someone at Microsoft might know of
> > a solution.
> >
> This is likely not a Profiler issue, but a SQL Trace API one on the
> server. I assume the problem occurs from all clients, including the
> server itself.
> I might consider opening a support case with Microsoft... and then
> sharing the solution with the rest of us :-)
> In any case, I assume you are running SP3a or SP4 on the server. Is that
> correct?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
David,
Indeed weâ're running Sp3a on a Win 2000 Sp4 box.
It would seem that the Trace API is no longer functioning correctly, so the
only solution maybe a call to Microsoft.
Thanks for your reply anyway.
Anto
On one server that I administer, when running a Profiler trace (either
through the GUI or directly using the stored procs) the â'Readsâ' column always
returns 0 no matter what event is being monitored.
The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
Thanks in advance,
AntoIrishAnto wrote:
> I wonder if anyone here knows what the problem is.
> On one server that I administer, when running a Profiler trace (either
> through the GUI or directly using the stored procs) the â'Readsâ'
> column always returns 0 no matter what event is being monitored.
> The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
> Thanks in advance,
> Anto
I saw this reported once on a customer who used EMC disks and broke a
cluster to make two stand-alone installs of SQL Server. That's when the
read statistics were no longer were captured. I can't say I remember
what the solution was.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com|||"David Gugick" wrote:
> IrishAnto wrote:
> > I wonder if anyone here knows what the problem is.
> >
> > On one server that I administer, when running a Profiler trace (either
> > through the GUI or directly using the stored procs) the â'Readsâ'
> > column always returns 0 no matter what event is being monitored.
> >
> > The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
> >
> > Thanks in advance,
> >
> > Anto
> I saw this reported once on a customer who used EMC disks and broke a
> cluster to make two stand-alone installs of SQL Server. That's when the
> read statistics were no longer were captured. I can't say I remember
> what the solution was.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
The server in question was never part of a cluster. As far as I'm aware
profiler used to return values in the reads column, but no longer.
I've seen other message boards with the same problem posted, but with no
answers. I was hoping someone at Microsoft might know of a solution.
Anto|||IrishAnto wrote:
> The server in question was never part of a cluster. As far as I'm
> aware profiler used to return values in the reads column, but no
> longer. I've seen other message boards with the same problem posted,
> but with no answers. I was hoping someone at Microsoft might know of
> a solution.
>
This is likely not a Profiler issue, but a SQL Trace API one on the
server. I assume the problem occurs from all clients, including the
server itself.
I might consider opening a support case with Microsoft... and then
sharing the solution with the rest of us :-)
In any case, I assume you are running SP3a or SP4 on the server. Is that
correct?
David Gugick
Quest Software
www.imceda.com
www.quest.com|||"David Gugick" wrote:
> IrishAnto wrote:
> > The server in question was never part of a cluster. As far as I'm
> > aware profiler used to return values in the reads column, but no
> > longer. I've seen other message boards with the same problem posted,
> > but with no answers. I was hoping someone at Microsoft might know of
> > a solution.
> >
> This is likely not a Profiler issue, but a SQL Trace API one on the
> server. I assume the problem occurs from all clients, including the
> server itself.
> I might consider opening a support case with Microsoft... and then
> sharing the solution with the rest of us :-)
> In any case, I assume you are running SP3a or SP4 on the server. Is that
> correct?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
David,
Indeed weâ're running Sp3a on a Win 2000 Sp4 box.
It would seem that the Trace API is no longer functioning correctly, so the
only solution maybe a call to Microsoft.
Thanks for your reply anyway.
Anto
Odd problem with Profiler
I wonder if anyone here knows what the problem is.
On one server that I administer, when running a Profiler trace (either
through the GUI or directly using the stored procs) the “Reads” column always
returns 0 no matter what event is being monitored.
The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
Thanks in advance,
Anto
IrishAnto wrote:
> I wonder if anyone here knows what the problem is.
> On one server that I administer, when running a Profiler trace (either
> through the GUI or directly using the stored procs) the “Reads”
> column always returns 0 no matter what event is being monitored.
> The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
> Thanks in advance,
> Anto
I saw this reported once on a customer who used EMC disks and broke a
cluster to make two stand-alone installs of SQL Server. That's when the
read statistics were no longer were captured. I can't say I remember
what the solution was.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||"David Gugick" wrote:
> IrishAnto wrote:
> I saw this reported once on a customer who used EMC disks and broke a
> cluster to make two stand-alone installs of SQL Server. That's when the
> read statistics were no longer were captured. I can't say I remember
> what the solution was.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
The server in question was never part of a cluster. As far as I'm aware
profiler used to return values in the reads column, but no longer.
I've seen other message boards with the same problem posted, but with no
answers. I was hoping someone at Microsoft might know of a solution.
Anto
|||IrishAnto wrote:
> The server in question was never part of a cluster. As far as I'm
> aware profiler used to return values in the reads column, but no
> longer. I've seen other message boards with the same problem posted,
> but with no answers. I was hoping someone at Microsoft might know of
> a solution.
>
This is likely not a Profiler issue, but a SQL Trace API one on the
server. I assume the problem occurs from all clients, including the
server itself.
I might consider opening a support case with Microsoft... and then
sharing the solution with the rest of us :-)
In any case, I assume you are running SP3a or SP4 on the server. Is that
correct?
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||"David Gugick" wrote:
> IrishAnto wrote:
> This is likely not a Profiler issue, but a SQL Trace API one on the
> server. I assume the problem occurs from all clients, including the
> server itself.
> I might consider opening a support case with Microsoft... and then
> sharing the solution with the rest of us :-)
> In any case, I assume you are running SP3a or SP4 on the server. Is that
> correct?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
David,
Indeed we’re running Sp3a on a Win 2000 Sp4 box.
It would seem that the Trace API is no longer functioning correctly, so the
only solution maybe a call to Microsoft.
Thanks for your reply anyway.
Anto
sql
On one server that I administer, when running a Profiler trace (either
through the GUI or directly using the stored procs) the “Reads” column always
returns 0 no matter what event is being monitored.
The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
Thanks in advance,
Anto
IrishAnto wrote:
> I wonder if anyone here knows what the problem is.
> On one server that I administer, when running a Profiler trace (either
> through the GUI or directly using the stored procs) the “Reads”
> column always returns 0 no matter what event is being monitored.
> The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
> Thanks in advance,
> Anto
I saw this reported once on a customer who used EMC disks and broke a
cluster to make two stand-alone installs of SQL Server. That's when the
read statistics were no longer were captured. I can't say I remember
what the solution was.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||"David Gugick" wrote:
> IrishAnto wrote:
> I saw this reported once on a customer who used EMC disks and broke a
> cluster to make two stand-alone installs of SQL Server. That's when the
> read statistics were no longer were captured. I can't say I remember
> what the solution was.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
The server in question was never part of a cluster. As far as I'm aware
profiler used to return values in the reads column, but no longer.
I've seen other message boards with the same problem posted, but with no
answers. I was hoping someone at Microsoft might know of a solution.
Anto
|||IrishAnto wrote:
> The server in question was never part of a cluster. As far as I'm
> aware profiler used to return values in the reads column, but no
> longer. I've seen other message boards with the same problem posted,
> but with no answers. I was hoping someone at Microsoft might know of
> a solution.
>
This is likely not a Profiler issue, but a SQL Trace API one on the
server. I assume the problem occurs from all clients, including the
server itself.
I might consider opening a support case with Microsoft... and then
sharing the solution with the rest of us :-)
In any case, I assume you are running SP3a or SP4 on the server. Is that
correct?
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||"David Gugick" wrote:
> IrishAnto wrote:
> This is likely not a Profiler issue, but a SQL Trace API one on the
> server. I assume the problem occurs from all clients, including the
> server itself.
> I might consider opening a support case with Microsoft... and then
> sharing the solution with the rest of us :-)
> In any case, I assume you are running SP3a or SP4 on the server. Is that
> correct?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
David,
Indeed we’re running Sp3a on a Win 2000 Sp4 box.
It would seem that the Trace API is no longer functioning correctly, so the
only solution maybe a call to Microsoft.
Thanks for your reply anyway.
Anto
sql
Odd problem with Profiler
I wonder if anyone here knows what the problem is.
On one server that I administer, when running a Profiler trace (either
through the GUI or directly using the stored procs) the “Reads” column a
lways
returns 0 no matter what event is being monitored.
The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
Thanks in advance,
AntoIrishAnto wrote:
> I wonder if anyone here knows what the problem is.
> On one server that I administer, when running a Profiler trace (either
> through the GUI or directly using the stored procs) the “Reads”
> column always returns 0 no matter what event is being monitored.
> The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
> Thanks in advance,
> Anto
I saw this reported once on a customer who used EMC disks and broke a
cluster to make two stand-alone installs of SQL Server. That's when the
read statistics were no longer were captured. I can't say I remember
what the solution was.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||"David Gugick" wrote:
> IrishAnto wrote:
> I saw this reported once on a customer who used EMC disks and broke a
> cluster to make two stand-alone installs of SQL Server. That's when the
> read statistics were no longer were captured. I can't say I remember
> what the solution was.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
The server in question was never part of a cluster. As far as I'm aware
profiler used to return values in the reads column, but no longer.
I've seen other message boards with the same problem posted, but with no
answers. I was hoping someone at Microsoft might know of a solution.
Anto|||IrishAnto wrote:
> The server in question was never part of a cluster. As far as I'm
> aware profiler used to return values in the reads column, but no
> longer. I've seen other message boards with the same problem posted,
> but with no answers. I was hoping someone at Microsoft might know of
> a solution.
>
This is likely not a Profiler issue, but a SQL Trace API one on the
server. I assume the problem occurs from all clients, including the
server itself.
I might consider opening a support case with Microsoft... and then
sharing the solution with the rest of us :-)
In any case, I assume you are running SP3a or SP4 on the server. Is that
correct?
David Gugick
Quest Software
www.imceda.com
www.quest.com|||"David Gugick" wrote:
> IrishAnto wrote:
> This is likely not a Profiler issue, but a SQL Trace API one on the
> server. I assume the problem occurs from all clients, including the
> server itself.
> I might consider opening a support case with Microsoft... and then
> sharing the solution with the rest of us :-)
> In any case, I assume you are running SP3a or SP4 on the server. Is that
> correct?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
David,
Indeed we’re running Sp3a on a Win 2000 Sp4 box.
It would seem that the Trace API is no longer functioning correctly, so the
only solution maybe a call to Microsoft.
Thanks for your reply anyway.
Anto
On one server that I administer, when running a Profiler trace (either
through the GUI or directly using the stored procs) the “Reads” column a
lways
returns 0 no matter what event is being monitored.
The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
Thanks in advance,
AntoIrishAnto wrote:
> I wonder if anyone here knows what the problem is.
> On one server that I administer, when running a Profiler trace (either
> through the GUI or directly using the stored procs) the “Reads”
> column always returns 0 no matter what event is being monitored.
> The server runs SQL 2000 Enterprise Edition sp3 on Win 2000 sp4.
> Thanks in advance,
> Anto
I saw this reported once on a customer who used EMC disks and broke a
cluster to make two stand-alone installs of SQL Server. That's when the
read statistics were no longer were captured. I can't say I remember
what the solution was.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||"David Gugick" wrote:
> IrishAnto wrote:
> I saw this reported once on a customer who used EMC disks and broke a
> cluster to make two stand-alone installs of SQL Server. That's when the
> read statistics were no longer were captured. I can't say I remember
> what the solution was.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
The server in question was never part of a cluster. As far as I'm aware
profiler used to return values in the reads column, but no longer.
I've seen other message boards with the same problem posted, but with no
answers. I was hoping someone at Microsoft might know of a solution.
Anto|||IrishAnto wrote:
> The server in question was never part of a cluster. As far as I'm
> aware profiler used to return values in the reads column, but no
> longer. I've seen other message boards with the same problem posted,
> but with no answers. I was hoping someone at Microsoft might know of
> a solution.
>
This is likely not a Profiler issue, but a SQL Trace API one on the
server. I assume the problem occurs from all clients, including the
server itself.
I might consider opening a support case with Microsoft... and then
sharing the solution with the rest of us :-)
In any case, I assume you are running SP3a or SP4 on the server. Is that
correct?
David Gugick
Quest Software
www.imceda.com
www.quest.com|||"David Gugick" wrote:
> IrishAnto wrote:
> This is likely not a Profiler issue, but a SQL Trace API one on the
> server. I assume the problem occurs from all clients, including the
> server itself.
> I might consider opening a support case with Microsoft... and then
> sharing the solution with the rest of us :-)
> In any case, I assume you are running SP3a or SP4 on the server. Is that
> correct?
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
>
David,
Indeed we’re running Sp3a on a Win 2000 Sp4 box.
It would seem that the Trace API is no longer functioning correctly, so the
only solution maybe a call to Microsoft.
Thanks for your reply anyway.
Anto
Subscribe to:
Posts (Atom)