Has anyone else had any problems with cubes showing incorrect aggregates?
For instance, the sales for a Quarter is showing twice the amount of the 3
months showing. As well, there are values associated to products (lowest
level in dimension) that should not be there. When I re-process the cubes,
the issues are eventually resolved but I feel that I cannot trust any numbers
that the cubes show now.
Thanks in advance
Data Integrity starts at the souce and, once validated, is only maintained
through constraints.
The old adage applies here: Garbage In, Garbage Out.
I'd look at the integrity constraints of the primary sources. If those look
intact, I'd attempt to run manual queries to aggregate the data to see if any
anomolies show up. Finally, if all looks well, the next time some
abnormality shows up in the cube, instead of reprocessing, I'd look at the
source first to see if you could manually replicate the numbers.
I have not seen what you are describing except where there were data errors
in the sources. But if you feel that all has been checked out, I would most
certainly open up a PSS case.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> Has anyone else had any problems with cubes showing incorrect aggregates?
> For instance, the sales for a Quarter is showing twice the amount of the 3
> months showing. As well, there are values associated to products (lowest
> level in dimension) that should not be there. When I re-process the cubes,
> the issues are eventually resolved but I feel that I cannot trust any numbers
> that the cubes show now.
> Thanks in advance
|||I agree, Garbage In, Garbage Out. I have experience more than I want to.
In this case however, the data is clean. It has been checked and double
checked. There are no problems with this set of data. Could this have
anything to do with how I have designed my aggregates or writeback issues?
"AnthonyThomas" wrote:
[vbcol=seagreen]
> Data Integrity starts at the souce and, once validated, is only maintained
> through constraints.
> The old adage applies here: Garbage In, Garbage Out.
> I'd look at the integrity constraints of the primary sources. If those look
> intact, I'd attempt to run manual queries to aggregate the data to see if any
> anomolies show up. Finally, if all looks well, the next time some
> abnormality shows up in the cube, instead of reprocessing, I'd look at the
> source first to see if you could manually replicate the numbers.
> I have not seen what you are describing except where there were data errors
> in the sources. But if you feel that all has been checked out, I would most
> certainly open up a PSS case.
> Sincerely,
>
> Anthony Thomas
>
> "fastforward" wrote:
|||Data integrity is always issue number one but if you've checked that out,
then logic comes next. I'd run the aggregate process manually on a few
deminsions with normal T-SQL aggregates. Then, most certainly, I would
consider a more simple design for your cubes to see if the problem clears up.
If so, I'd add complexity, one layer at a time.
If you continue to run into aggregations issues, I would most certainly
consider contacting MS PSS.
Sincerely,
Anthony Thomas
"fastforward" wrote:
[vbcol=seagreen]
> I agree, Garbage In, Garbage Out. I have experience more than I want to.
> In this case however, the data is clean. It has been checked and double
> checked. There are no problems with this set of data. Could this have
> anything to do with how I have designed my aggregates or writeback issues?
> "AnthonyThomas" wrote:
Showing posts with label showing. Show all posts
Showing posts with label showing. Show all posts
Thursday, March 8, 2012
Aggregate integrity problems
Has anyone else had any problems with cubes showing incorrect aggregates?
For instance, the sales for a Quarter is showing twice the amount of the 3
months showing. As well, there are values associated to products (lowest
level in dimension) that should not be there. When I re-process the cubes,
the issues are eventually resolved but I feel that I cannot trust any numbers
that the cubes show now.
Thanks in advanceData Integrity starts at the souce and, once validated, is only maintained
through constraints.
The old adage applies here: Garbage In, Garbage Out.
I'd look at the integrity constraints of the primary sources. If those look
intact, I'd attempt to run manual queries to aggregate the data to see if any
anomolies show up. Finally, if all looks well, the next time some
abnormality shows up in the cube, instead of reprocessing, I'd look at the
source first to see if you could manually replicate the numbers.
I have not seen what you are describing except where there were data errors
in the sources. But if you feel that all has been checked out, I would most
certainly open up a PSS case.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> Has anyone else had any problems with cubes showing incorrect aggregates?
> For instance, the sales for a Quarter is showing twice the amount of the 3
> months showing. As well, there are values associated to products (lowest
> level in dimension) that should not be there. When I re-process the cubes,
> the issues are eventually resolved but I feel that I cannot trust any numbers
> that the cubes show now.
> Thanks in advance|||I agree, Garbage In, Garbage Out. I have experience more than I want to.
In this case however, the data is clean. It has been checked and double
checked. There are no problems with this set of data. Could this have
anything to do with how I have designed my aggregates or writeback issues?
"AnthonyThomas" wrote:
> Data Integrity starts at the souce and, once validated, is only maintained
> through constraints.
> The old adage applies here: Garbage In, Garbage Out.
> I'd look at the integrity constraints of the primary sources. If those look
> intact, I'd attempt to run manual queries to aggregate the data to see if any
> anomolies show up. Finally, if all looks well, the next time some
> abnormality shows up in the cube, instead of reprocessing, I'd look at the
> source first to see if you could manually replicate the numbers.
> I have not seen what you are describing except where there were data errors
> in the sources. But if you feel that all has been checked out, I would most
> certainly open up a PSS case.
> Sincerely,
>
> Anthony Thomas
>
> "fastforward" wrote:
> > Has anyone else had any problems with cubes showing incorrect aggregates?
> > For instance, the sales for a Quarter is showing twice the amount of the 3
> > months showing. As well, there are values associated to products (lowest
> > level in dimension) that should not be there. When I re-process the cubes,
> > the issues are eventually resolved but I feel that I cannot trust any numbers
> > that the cubes show now.
> >
> > Thanks in advance|||Data integrity is always issue number one but if you've checked that out,
then logic comes next. I'd run the aggregate process manually on a few
deminsions with normal T-SQL aggregates. Then, most certainly, I would
consider a more simple design for your cubes to see if the problem clears up.
If so, I'd add complexity, one layer at a time.
If you continue to run into aggregations issues, I would most certainly
consider contacting MS PSS.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> I agree, Garbage In, Garbage Out. I have experience more than I want to.
> In this case however, the data is clean. It has been checked and double
> checked. There are no problems with this set of data. Could this have
> anything to do with how I have designed my aggregates or writeback issues?
> "AnthonyThomas" wrote:
> > Data Integrity starts at the souce and, once validated, is only maintained
> > through constraints.
> >
> > The old adage applies here: Garbage In, Garbage Out.
> >
> > I'd look at the integrity constraints of the primary sources. If those look
> > intact, I'd attempt to run manual queries to aggregate the data to see if any
> > anomolies show up. Finally, if all looks well, the next time some
> > abnormality shows up in the cube, instead of reprocessing, I'd look at the
> > source first to see if you could manually replicate the numbers.
> >
> > I have not seen what you are describing except where there were data errors
> > in the sources. But if you feel that all has been checked out, I would most
> > certainly open up a PSS case.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> > "fastforward" wrote:
> >
> > > Has anyone else had any problems with cubes showing incorrect aggregates?
> > > For instance, the sales for a Quarter is showing twice the amount of the 3
> > > months showing. As well, there are values associated to products (lowest
> > > level in dimension) that should not be there. When I re-process the cubes,
> > > the issues are eventually resolved but I feel that I cannot trust any numbers
> > > that the cubes show now.
> > >
> > > Thanks in advance
For instance, the sales for a Quarter is showing twice the amount of the 3
months showing. As well, there are values associated to products (lowest
level in dimension) that should not be there. When I re-process the cubes,
the issues are eventually resolved but I feel that I cannot trust any numbers
that the cubes show now.
Thanks in advanceData Integrity starts at the souce and, once validated, is only maintained
through constraints.
The old adage applies here: Garbage In, Garbage Out.
I'd look at the integrity constraints of the primary sources. If those look
intact, I'd attempt to run manual queries to aggregate the data to see if any
anomolies show up. Finally, if all looks well, the next time some
abnormality shows up in the cube, instead of reprocessing, I'd look at the
source first to see if you could manually replicate the numbers.
I have not seen what you are describing except where there were data errors
in the sources. But if you feel that all has been checked out, I would most
certainly open up a PSS case.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> Has anyone else had any problems with cubes showing incorrect aggregates?
> For instance, the sales for a Quarter is showing twice the amount of the 3
> months showing. As well, there are values associated to products (lowest
> level in dimension) that should not be there. When I re-process the cubes,
> the issues are eventually resolved but I feel that I cannot trust any numbers
> that the cubes show now.
> Thanks in advance|||I agree, Garbage In, Garbage Out. I have experience more than I want to.
In this case however, the data is clean. It has been checked and double
checked. There are no problems with this set of data. Could this have
anything to do with how I have designed my aggregates or writeback issues?
"AnthonyThomas" wrote:
> Data Integrity starts at the souce and, once validated, is only maintained
> through constraints.
> The old adage applies here: Garbage In, Garbage Out.
> I'd look at the integrity constraints of the primary sources. If those look
> intact, I'd attempt to run manual queries to aggregate the data to see if any
> anomolies show up. Finally, if all looks well, the next time some
> abnormality shows up in the cube, instead of reprocessing, I'd look at the
> source first to see if you could manually replicate the numbers.
> I have not seen what you are describing except where there were data errors
> in the sources. But if you feel that all has been checked out, I would most
> certainly open up a PSS case.
> Sincerely,
>
> Anthony Thomas
>
> "fastforward" wrote:
> > Has anyone else had any problems with cubes showing incorrect aggregates?
> > For instance, the sales for a Quarter is showing twice the amount of the 3
> > months showing. As well, there are values associated to products (lowest
> > level in dimension) that should not be there. When I re-process the cubes,
> > the issues are eventually resolved but I feel that I cannot trust any numbers
> > that the cubes show now.
> >
> > Thanks in advance|||Data integrity is always issue number one but if you've checked that out,
then logic comes next. I'd run the aggregate process manually on a few
deminsions with normal T-SQL aggregates. Then, most certainly, I would
consider a more simple design for your cubes to see if the problem clears up.
If so, I'd add complexity, one layer at a time.
If you continue to run into aggregations issues, I would most certainly
consider contacting MS PSS.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> I agree, Garbage In, Garbage Out. I have experience more than I want to.
> In this case however, the data is clean. It has been checked and double
> checked. There are no problems with this set of data. Could this have
> anything to do with how I have designed my aggregates or writeback issues?
> "AnthonyThomas" wrote:
> > Data Integrity starts at the souce and, once validated, is only maintained
> > through constraints.
> >
> > The old adage applies here: Garbage In, Garbage Out.
> >
> > I'd look at the integrity constraints of the primary sources. If those look
> > intact, I'd attempt to run manual queries to aggregate the data to see if any
> > anomolies show up. Finally, if all looks well, the next time some
> > abnormality shows up in the cube, instead of reprocessing, I'd look at the
> > source first to see if you could manually replicate the numbers.
> >
> > I have not seen what you are describing except where there were data errors
> > in the sources. But if you feel that all has been checked out, I would most
> > certainly open up a PSS case.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> > "fastforward" wrote:
> >
> > > Has anyone else had any problems with cubes showing incorrect aggregates?
> > > For instance, the sales for a Quarter is showing twice the amount of the 3
> > > months showing. As well, there are values associated to products (lowest
> > > level in dimension) that should not be there. When I re-process the cubes,
> > > the issues are eventually resolved but I feel that I cannot trust any numbers
> > > that the cubes show now.
> > >
> > > Thanks in advance
Aggregate integrity problems
Has anyone else had any problems with cubes showing incorrect aggregates?
For instance, the sales for a Quarter is showing twice the amount of the 3
months showing. As well, there are values associated to products (lowest
level in dimension) that should not be there. When I re-process the cubes,
the issues are eventually resolved but I feel that I cannot trust any number
s
that the cubes show now.
Thanks in advanceData Integrity starts at the souce and, once validated, is only maintained
through constraints.
The old adage applies here: Garbage In, Garbage Out.
I'd look at the integrity constraints of the primary sources. If those look
intact, I'd attempt to run manual queries to aggregate the data to see if an
y
anomolies show up. Finally, if all looks well, the next time some
abnormality shows up in the cube, instead of reprocessing, I'd look at the
source first to see if you could manually replicate the numbers.
I have not seen what you are describing except where there were data errors
in the sources. But if you feel that all has been checked out, I would most
certainly open up a PSS case.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> Has anyone else had any problems with cubes showing incorrect aggregates?
> For instance, the sales for a Quarter is showing twice the amount of the 3
> months showing. As well, there are values associated to products (lowest
> level in dimension) that should not be there. When I re-process the cubes
,
> the issues are eventually resolved but I feel that I cannot trust any numb
ers
> that the cubes show now.
> Thanks in advance|||I agree, Garbage In, Garbage Out. I have experience more than I want to.
In this case however, the data is clean. It has been checked and double
checked. There are no problems with this set of data. Could this have
anything to do with how I have designed my aggregates or writeback issues?
"AnthonyThomas" wrote:
[vbcol=seagreen]
> Data Integrity starts at the souce and, once validated, is only maintained
> through constraints.
> The old adage applies here: Garbage In, Garbage Out.
> I'd look at the integrity constraints of the primary sources. If those lo
ok
> intact, I'd attempt to run manual queries to aggregate the data to see if
any
> anomolies show up. Finally, if all looks well, the next time some
> abnormality shows up in the cube, instead of reprocessing, I'd look at the
> source first to see if you could manually replicate the numbers.
> I have not seen what you are describing except where there were data error
s
> in the sources. But if you feel that all has been checked out, I would mo
st
> certainly open up a PSS case.
> Sincerely,
>
> Anthony Thomas
>
> "fastforward" wrote:
>|||Data integrity is always issue number one but if you've checked that out,
then logic comes next. I'd run the aggregate process manually on a few
deminsions with normal T-SQL aggregates. Then, most certainly, I would
consider a more simple design for your cubes to see if the problem clears up
.
If so, I'd add complexity, one layer at a time.
If you continue to run into aggregations issues, I would most certainly
consider contacting MS PSS.
Sincerely,
Anthony Thomas
"fastforward" wrote:
[vbcol=seagreen]
> I agree, Garbage In, Garbage Out. I have experience more than I want to.
> In this case however, the data is clean. It has been checked and double
> checked. There are no problems with this set of data. Could this have
> anything to do with how I have designed my aggregates or writeback issues?
> "AnthonyThomas" wrote:
>
For instance, the sales for a Quarter is showing twice the amount of the 3
months showing. As well, there are values associated to products (lowest
level in dimension) that should not be there. When I re-process the cubes,
the issues are eventually resolved but I feel that I cannot trust any number
s
that the cubes show now.
Thanks in advanceData Integrity starts at the souce and, once validated, is only maintained
through constraints.
The old adage applies here: Garbage In, Garbage Out.
I'd look at the integrity constraints of the primary sources. If those look
intact, I'd attempt to run manual queries to aggregate the data to see if an
y
anomolies show up. Finally, if all looks well, the next time some
abnormality shows up in the cube, instead of reprocessing, I'd look at the
source first to see if you could manually replicate the numbers.
I have not seen what you are describing except where there were data errors
in the sources. But if you feel that all has been checked out, I would most
certainly open up a PSS case.
Sincerely,
Anthony Thomas
"fastforward" wrote:
> Has anyone else had any problems with cubes showing incorrect aggregates?
> For instance, the sales for a Quarter is showing twice the amount of the 3
> months showing. As well, there are values associated to products (lowest
> level in dimension) that should not be there. When I re-process the cubes
,
> the issues are eventually resolved but I feel that I cannot trust any numb
ers
> that the cubes show now.
> Thanks in advance|||I agree, Garbage In, Garbage Out. I have experience more than I want to.
In this case however, the data is clean. It has been checked and double
checked. There are no problems with this set of data. Could this have
anything to do with how I have designed my aggregates or writeback issues?
"AnthonyThomas" wrote:
[vbcol=seagreen]
> Data Integrity starts at the souce and, once validated, is only maintained
> through constraints.
> The old adage applies here: Garbage In, Garbage Out.
> I'd look at the integrity constraints of the primary sources. If those lo
ok
> intact, I'd attempt to run manual queries to aggregate the data to see if
any
> anomolies show up. Finally, if all looks well, the next time some
> abnormality shows up in the cube, instead of reprocessing, I'd look at the
> source first to see if you could manually replicate the numbers.
> I have not seen what you are describing except where there were data error
s
> in the sources. But if you feel that all has been checked out, I would mo
st
> certainly open up a PSS case.
> Sincerely,
>
> Anthony Thomas
>
> "fastforward" wrote:
>|||Data integrity is always issue number one but if you've checked that out,
then logic comes next. I'd run the aggregate process manually on a few
deminsions with normal T-SQL aggregates. Then, most certainly, I would
consider a more simple design for your cubes to see if the problem clears up
.
If so, I'd add complexity, one layer at a time.
If you continue to run into aggregations issues, I would most certainly
consider contacting MS PSS.
Sincerely,
Anthony Thomas
"fastforward" wrote:
[vbcol=seagreen]
> I agree, Garbage In, Garbage Out. I have experience more than I want to.
> In this case however, the data is clean. It has been checked and double
> checked. There are no problems with this set of data. Could this have
> anything to do with how I have designed my aggregates or writeback issues?
> "AnthonyThomas" wrote:
>
Thursday, February 16, 2012
After Restore Identity Column mess up
When restore the data from last night backup agter a server failure. My
identiy column values are mess up and showing a different id than was before.
I have this as primary key in my table and store into user station as cookies.
What is wrong an dhow to fix it.
Help desperate
Thansk
TanweerI don't know exactly what you are doing but I can't duplicate the problem you
are having. Something is amiss. Are you POSITIVE that your backup file
contains the IDENTITY values that you think they contain? Restore a test
database under a different name and check it out.|||I tried it on other database and they are ok however this database after a
disk crash is behaving like this.
Thanks
"Scagnetti" wrote:
> I don't know exactly what you are doing but I can't duplicate the problem you
> are having. Something is amiss. Are you POSITIVE that your backup file
> contains the IDENTITY values that you think they contain? Restore a test
> database under a different name and check it out.|||Disk crash... Any errors from DBCC CHECKDB?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tanweer" <Tanweer@.discussions.microsoft.com> wrote in message
news:07EE4B98-1A80-4606-95DB-3A7ABAF971C3@.microsoft.com...
>I tried it on other database and they are ok however this database after a
> disk crash is behaving like this.
> Thanks
>
> "Scagnetti" wrote:
>> I don't know exactly what you are doing but I can't duplicate the problem you
>> are having. Something is amiss. Are you POSITIVE that your backup file
>> contains the IDENTITY values that you think they contain? Restore a test
>> database under a different name and check it out.
identiy column values are mess up and showing a different id than was before.
I have this as primary key in my table and store into user station as cookies.
What is wrong an dhow to fix it.
Help desperate
Thansk
TanweerI don't know exactly what you are doing but I can't duplicate the problem you
are having. Something is amiss. Are you POSITIVE that your backup file
contains the IDENTITY values that you think they contain? Restore a test
database under a different name and check it out.|||I tried it on other database and they are ok however this database after a
disk crash is behaving like this.
Thanks
"Scagnetti" wrote:
> I don't know exactly what you are doing but I can't duplicate the problem you
> are having. Something is amiss. Are you POSITIVE that your backup file
> contains the IDENTITY values that you think they contain? Restore a test
> database under a different name and check it out.|||Disk crash... Any errors from DBCC CHECKDB?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tanweer" <Tanweer@.discussions.microsoft.com> wrote in message
news:07EE4B98-1A80-4606-95DB-3A7ABAF971C3@.microsoft.com...
>I tried it on other database and they are ok however this database after a
> disk crash is behaving like this.
> Thanks
>
> "Scagnetti" wrote:
>> I don't know exactly what you are doing but I can't duplicate the problem you
>> are having. Something is amiss. Are you POSITIVE that your backup file
>> contains the IDENTITY values that you think they contain? Restore a test
>> database under a different name and check it out.
After Restore Identity Column mess up
When restore the data from last night backup agter a server failure. My
identiy column values are mess up and showing a different id than was before
.
I have this as primary key in my table and store into user station as cookie
s.
What is wrong an dhow to fix it.
Help desperate
Thansk
TanweerI don't know exactly what you are doing but I can't duplicate the problem yo
u
are having. Something is amiss. Are you POSITIVE that your backup file
contains the IDENTITY values that you think they contain? Restore a test
database under a different name and check it out.|||I tried it on other database and they are ok however this database after a
disk crash is behaving like this.
Thanks
"Scagnetti" wrote:
> I don't know exactly what you are doing but I can't duplicate the problem
you
> are having. Something is amiss. Are you POSITIVE that your backup file
> contains the IDENTITY values that you think they contain? Restore a test
> database under a different name and check it out.|||Disk crash... Any errors from DBCC CHECKDB?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tanweer" <Tanweer@.discussions.microsoft.com> wrote in message
news:07EE4B98-1A80-4606-95DB-3A7ABAF971C3@.microsoft.com...[vbcol=seagreen]
>I tried it on other database and they are ok however this database after a
> disk crash is behaving like this.
> Thanks
>
> "Scagnetti" wrote:
>
identiy column values are mess up and showing a different id than was before
.
I have this as primary key in my table and store into user station as cookie
s.
What is wrong an dhow to fix it.
Help desperate
Thansk
TanweerI don't know exactly what you are doing but I can't duplicate the problem yo
u
are having. Something is amiss. Are you POSITIVE that your backup file
contains the IDENTITY values that you think they contain? Restore a test
database under a different name and check it out.|||I tried it on other database and they are ok however this database after a
disk crash is behaving like this.
Thanks
"Scagnetti" wrote:
> I don't know exactly what you are doing but I can't duplicate the problem
you
> are having. Something is amiss. Are you POSITIVE that your backup file
> contains the IDENTITY values that you think they contain? Restore a test
> database under a different name and check it out.|||Disk crash... Any errors from DBCC CHECKDB?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tanweer" <Tanweer@.discussions.microsoft.com> wrote in message
news:07EE4B98-1A80-4606-95DB-3A7ABAF971C3@.microsoft.com...[vbcol=seagreen]
>I tried it on other database and they are ok however this database after a
> disk crash is behaving like this.
> Thanks
>
> "Scagnetti" wrote:
>
After Restore Identity Column mess up
When restore the data from last night backup agter a server failure. My
identiy column values are mess up and showing a different id than was before.
I have this as primary key in my table and store into user station as cookies.
What is wrong an dhow to fix it.
Help desperate
Thansk
Tanweer
I don't know exactly what you are doing but I can't duplicate the problem you
are having. Something is amiss. Are you POSITIVE that your backup file
contains the IDENTITY values that you think they contain? Restore a test
database under a different name and check it out.
|||I tried it on other database and they are ok however this database after a
disk crash is behaving like this.
Thanks
"Scagnetti" wrote:
> I don't know exactly what you are doing but I can't duplicate the problem you
> are having. Something is amiss. Are you POSITIVE that your backup file
> contains the IDENTITY values that you think they contain? Restore a test
> database under a different name and check it out.
|||Disk crash... Any errors from DBCC CHECKDB?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tanweer" <Tanweer@.discussions.microsoft.com> wrote in message
news:07EE4B98-1A80-4606-95DB-3A7ABAF971C3@.microsoft.com...[vbcol=seagreen]
>I tried it on other database and they are ok however this database after a
> disk crash is behaving like this.
> Thanks
>
> "Scagnetti" wrote:
identiy column values are mess up and showing a different id than was before.
I have this as primary key in my table and store into user station as cookies.
What is wrong an dhow to fix it.
Help desperate
Thansk
Tanweer
I don't know exactly what you are doing but I can't duplicate the problem you
are having. Something is amiss. Are you POSITIVE that your backup file
contains the IDENTITY values that you think they contain? Restore a test
database under a different name and check it out.
|||I tried it on other database and they are ok however this database after a
disk crash is behaving like this.
Thanks
"Scagnetti" wrote:
> I don't know exactly what you are doing but I can't duplicate the problem you
> are having. Something is amiss. Are you POSITIVE that your backup file
> contains the IDENTITY values that you think they contain? Restore a test
> database under a different name and check it out.
|||Disk crash... Any errors from DBCC CHECKDB?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tanweer" <Tanweer@.discussions.microsoft.com> wrote in message
news:07EE4B98-1A80-4606-95DB-3A7ABAF971C3@.microsoft.com...[vbcol=seagreen]
>I tried it on other database and they are ok however this database after a
> disk crash is behaving like this.
> Thanks
>
> "Scagnetti" wrote:
Monday, February 13, 2012
After installing active directory I failed to connect SQL server 2000
After installing active directory I failed to connect SQL server 2000 with
eather with Active directory user accont and sa.
It's showing a messege unable to connect sql server Mainserver\SQL2000DB
server msg 17, level16 state 1
server does not exist or access denied.
Please helpOn Nov 6, 5:26 am, "asif"<jossy...@.nospam.com> wrote:
> After installing active directory I failed to connect SQL server 2000 with
> eather with Active directory user accont and sa.
> It's showing a messege unable to connect sql server Mainserver\SQL2000DB
> server msg 17, level16 state 1
> server does not exist or access denied.
> Please help
first make sure sql server service is started. If the service does
not start you can not connect
second pay attention to servername when you're trying to connect. If
you created default instance then just the servername needed if named
instance created then the server name above should work.
eather with Active directory user accont and sa.
It's showing a messege unable to connect sql server Mainserver\SQL2000DB
server msg 17, level16 state 1
server does not exist or access denied.
Please helpOn Nov 6, 5:26 am, "asif"<jossy...@.nospam.com> wrote:
> After installing active directory I failed to connect SQL server 2000 with
> eather with Active directory user accont and sa.
> It's showing a messege unable to connect sql server Mainserver\SQL2000DB
> server msg 17, level16 state 1
> server does not exist or access denied.
> Please help
first make sure sql server service is started. If the service does
not start you can not connect
second pay attention to servername when you're trying to connect. If
you created default instance then just the servername needed if named
instance created then the server name above should work.
Subscribe to:
Posts (Atom)