Thursday, March 29, 2012
Error when using rskeymgmt to backup encryption key
following error:
The Report Server Windows service is not responding to RPC requests. The
service may not be running.
I have checked, and the service is running. We are using SQL Server 2005
sp2. The command I am using is:
rskeymgmt -e -fc:\rskey\rsdbkey.txt -psomepassword
Any ideas why this is failing. I was able to run the program some time ago.
Thanks.On May 2, 11:50 am, "Tim Kelley" <tkel...@.company.com> wrote:
> When I run the rskeymgmt program to backup the encryption key, I get the
> following error:
> The Report Server Windows service is not responding to RPC requests. The
> service may not be running.
> I have checked, and the service is running. We are using SQL Server 2005
> sp2. The command I am using is:
> rskeymgmt -e -fc:\rskey\rsdbkey.txt -psomepassword
> Any ideas why this is failing. I was able to run the program some time ago.
> Thanks.
This link might be helpful:
http://www.technologyone.org/new-6210113-3731.html
Regards,
Enrique Martinez
Sr. Software Consultant
Wednesday, March 21, 2012
Error when hiding subtotals in Report Builder
The following Report is OK, but when I unselect Show Subtotals, I get an error message.
Date | Count Result
-
10-10-2003 | 200000
-
Total | 200000
The error message is:
For more information about this error navigate to the report server on the local server machine, or enable remote errors
-
Semantic query execution failed.
-
Query execution failed for data set 'dataSet'.
-
An error has occurred during report processing.
I have tried experimenting with the GroupingBehaviour on EncourageGrouping or DiscourageGrouping, but without success. I seem to be the only one with this problem.
I am using Reporting Services 2005 in combination with Analysis Services 2005 (9.00.2153.00)Is this a bug in Reporting Services / Analysis Services 2005?
Does anybody have the same problem?
Friday, March 9, 2012
Error Violation of Primary Key While Attaching Database
I have been trying to attach a database but it fails because of
duplicate rows (Error 2627).
I searched in the Internet for removing duplicate records but it can
only work if I manage to attach the database first (correct me if I'm
wrong). So without having the database attached to the SQL server, I
will not manage to remove the duplicate rows. But when I tried to
attach, it checks for duplicate records automatically and fail to
attach.
Is there any workaround for my case?
Thanks in advance.
Regards,
Garreth Goh
BTW, it is SQL 2000 with SP3.
Regards,
Garreth Goh
On Dec 18, 10:02 am, gohtiamt...@.gmail.com wrote:
> Hello all,
> I have been trying to attach a database but it fails because of
> duplicate rows (Error 2627).
> I searched in the Internet for removing duplicate records but it can
> only work if I manage to attach the database first (correct me if I'm
> wrong). So without having the database attached to the SQL server, I
> will not manage to remove the duplicate rows. But when I tried to
> attach, it checks for duplicate records automatically and fail to
> attach.
> Is there any workaround for my case?
> Thanks in advance.
> Regards,
> Garreth Goh
|||Hi,
More updates after several attempts (with separate SQL server 2000
SP4).
01. I move the MDF and LDF files to another folders. I have two MDF
and two LDF files for one database.
02. I attach the same but blank backup database to my SQL server with
a new database name.
03. Back it up.
04. Restore the backup with the original database name in the initial
folder where the corrupted files were.
05. Detach the new restored (but empty) database.
06. Move the new created MDF and LDF files to another folder.
07. Copy the original corrupted MDF and LDF files back to the original
folder.
08. Attach the database. Got "Suspect" message.
09. Update "sysdatabases" to set the database into Emergency Mode.
10. Attach the database back. I got Emergency Mode.
11. Run "DBCC CHECKDB WITH NO_INFOMSGS" tells me to do
"REPAIR_ALLOW_DATA_LOSS".
12. Stop SQL services and run in Command Prompt "SQLSERVR -c -m" cause
it tells me to have Single-User mode when trying to run "DBCC
CHECKDB ...REPAIR_ALLOW_DATA_LOSS".
13. When I try to run "DBCC CHECKDB ...REPAIR_ALLOW_DATA_LOSS" in
this Single-Mode, it tells me "Could not run BEGIN TRANSACTION in
database 'MyDB' because the database is in bypass recovery mode."
I am stuck here. Could anyone here help, please?
I may have incorrectly listed down the sequence from point 8 to 11 but
my current status is at point 13.
Regards,
Garreth Goh
On Dec 18, 10:58 am, gohtiamt...@.gmail.com wrote:
> BTW, it is SQL 2000 with SP3.
> Regards,
> Garreth Goh
|||Or get Microsoft Technical Support on the phone.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
kgboles a earthlink dt net
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:261F6FD2-B073-42F2-A218-B3B6AFE3750D@.microsoft.com...
> The error pretty much speak for itself. My guess is that you have to try
> to export the data to a clean database, using some combination of script
> objects (unless you have DDL files to re-create them) and for the data
> SELECT INTO., INSERT SELECT, BCP etc.
> I would bring in an expert if above doesn't feel comfortable to you...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> <gohtiamtjai@.gmail.com> wrote in message
> news:078e33bc-1d03-4d24-a65b-96367d382dde@.a35g2000prf.googlegroups.com...
>
Error Violation of Primary Key While Attaching Database
I have been trying to attach a database but it fails because of
duplicate rows (Error 2627).
I searched in the Internet for removing duplicate records but it can
only work if I manage to attach the database first (correct me if I'm
wrong). So without having the database attached to the SQL server, I
will not manage to remove the duplicate rows. But when I tried to
attach, it checks for duplicate records automatically and fail to
attach.
Is there any workaround for my case?
Thanks in advance.
Regards,
Garreth GohBTW, it is SQL 2000 with SP3.
Regards,
Garreth Goh
On Dec 18, 10:02 am, gohtiamt...@.gmail.com wrote:
> Hello all,
> I have been trying to attach a database but it fails because of
> duplicate rows (Error 2627).
> I searched in the Internet for removing duplicate records but it can
> only work if I manage to attach the database first (correct me if I'm
> wrong). So without having the database attached to the SQL server, I
> will not manage to remove the duplicate rows. But when I tried to
> attach, it checks for duplicate records automatically and fail to
> attach.
> Is there any workaround for my case?
> Thanks in advance.
> Regards,
> Garreth Goh|||Hi,
More updates after several attempts (with separate SQL server 2000
SP4).
01. I move the MDF and LDF files to another folders. I have two MDF
and two LDF files for one database.
02. I attach the same but blank backup database to my SQL server with
a new database name.
03. Back it up.
04. Restore the backup with the original database name in the initial
folder where the corrupted files were.
05. Detach the new restored (but empty) database.
06. Move the new created MDF and LDF files to another folder.
07. Copy the original corrupted MDF and LDF files back to the original
folder.
08. Attach the database. Got "Suspect" message.
09. Update "sysdatabases" to set the database into Emergency Mode.
10. Attach the database back. I got Emergency Mode.
11. Run "DBCC CHECKDB WITH NO_INFOMSGS" tells me to do
"REPAIR_ALLOW_DATA_LOSS".
12. Stop SQL services and run in Command Prompt "SQLSERVR -c -m" cause
it tells me to have Single-User mode when trying to run "DBCC
CHECKDB ...REPAIR_ALLOW_DATA_LOSS".
13. When I try to run "DBCC CHECKDB ...REPAIR_ALLOW_DATA_LOSS" in
this Single-Mode, it tells me "Could not run BEGIN TRANSACTION in
database 'MyDB' because the database is in bypass recovery mode."
I am stuck here. Could anyone here help, please?
I may have incorrectly listed down the sequence from point 8 to 11 but
my current status is at point 13.
Regards,
Garreth Goh
On Dec 18, 10:58 am, gohtiamt...@.gmail.com wrote:
> BTW, it is SQL 2000 with SP3.
> Regards,
> Garreth Goh|||The error pretty much speak for itself. My guess is that you have to try to
export the data to a
clean database, using some combination of script objects (unless you have DD
L files to re-create
them) and for the data SELECT INTO., INSERT SELECT, BCP etc.
I would bring in an expert if above doesn't feel comfortable to you...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<gohtiamtjai@.gmail.com> wrote in message
news:078e33bc-1d03-4d24-a65b-96367d382dde@.a35g2000prf.googlegroups.com...[vbcol=seagreen]
> Hi,
> More updates after several attempts (with separate SQL server 2000
> SP4).
> 01. I move the MDF and LDF files to another folders. I have two MDF
> and two LDF files for one database.
> 02. I attach the same but blank backup database to my SQL server with
> a new database name.
> 03. Back it up.
> 04. Restore the backup with the original database name in the initial
> folder where the corrupted files were.
> 05. Detach the new restored (but empty) database.
> 06. Move the new created MDF and LDF files to another folder.
> 07. Copy the original corrupted MDF and LDF files back to the original
> folder.
> 08. Attach the database. Got "Suspect" message.
> 09. Update "sysdatabases" to set the database into Emergency Mode.
> 10. Attach the database back. I got Emergency Mode.
> 11. Run "DBCC CHECKDB WITH NO_INFOMSGS" tells me to do
> "REPAIR_ALLOW_DATA_LOSS".
> 12. Stop SQL services and run in Command Prompt "SQLSERVR -c -m" cause
> it tells me to have Single-User mode when trying to run "DBCC
> CHECKDB ...REPAIR_ALLOW_DATA_LOSS".
> 13. When I try to run "DBCC CHECKDB ...REPAIR_ALLOW_DATA_LOSS" in
> this Single-Mode, it tells me "Could not run BEGIN TRANSACTION in
> database 'MyDB' because the database is in bypass recovery mode."
> I am stuck here. Could anyone here help, please?
> I may have incorrectly listed down the sequence from point 8 to 11 but
> my current status is at point 13.
>
> Regards,
> Garreth Goh
>
> On Dec 18, 10:58 am, gohtiamt...@.gmail.com wrote:|||Or get Microsoft Technical Support on the phone.
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
kgboles a earthlink dt net
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:261F6FD2-B073-42F2-A218-B3B6AFE3750D@.microsoft.com...
> The error pretty much speak for itself. My guess is that you have to try
> to export the data to a clean database, using some combination of script
> objects (unless you have DDL files to re-create them) and for the data
> SELECT INTO., INSERT SELECT, BCP etc.
> I would bring in an expert if above doesn't feel comfortable to you...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> <gohtiamtjai@.gmail.com> wrote in message
> news:078e33bc-1d03-4d24-a65b-96367d382dde@.a35g2000prf.googlegroups.com...
>
Error Violation of Primary Key While Attaching Database
I have been trying to attach a database but it fails because of
duplicate rows (Error 2627).
I searched in the Internet for removing duplicate records but it can
only work if I manage to attach the database first (correct me if I'm
wrong). So without having the database attached to the SQL server, I
will not manage to remove the duplicate rows. But when I tried to
attach, it checks for duplicate records automatically and fail to
attach.
Is there any workaround for my case?
Thanks in advance.
Regards,
Garreth GohBTW, it is SQL 2000 with SP3.
Regards,
Garreth Goh
On Dec 18, 10:02 am, gohtiamt...@.gmail.com wrote:
> Hello all,
> I have been trying to attach a database but it fails because of
> duplicate rows (Error 2627).
> I searched in the Internet for removing duplicate records but it can
> only work if I manage to attach the database first (correct me if I'm
> wrong). So without having the database attached to the SQL server, I
> will not manage to remove the duplicate rows. But when I tried to
> attach, it checks for duplicate records automatically and fail to
> attach.
> Is there any workaround for my case?
> Thanks in advance.
> Regards,
> Garreth Goh|||Hi,
More updates after several attempts (with separate SQL server 2000
SP4).
01. I move the MDF and LDF files to another folders. I have two MDF
and two LDF files for one database.
02. I attach the same but blank backup database to my SQL server with
a new database name.
03. Back it up.
04. Restore the backup with the original database name in the initial
folder where the corrupted files were.
05. Detach the new restored (but empty) database.
06. Move the new created MDF and LDF files to another folder.
07. Copy the original corrupted MDF and LDF files back to the original
folder.
08. Attach the database. Got "Suspect" message.
09. Update "sysdatabases" to set the database into Emergency Mode.
10. Attach the database back. I got Emergency Mode.
11. Run "DBCC CHECKDB WITH NO_INFOMSGS" tells me to do
"REPAIR_ALLOW_DATA_LOSS".
12. Stop SQL services and run in Command Prompt "SQLSERVR -c -m" cause
it tells me to have Single-User mode when trying to run "DBCC
CHECKDB ...REPAIR_ALLOW_DATA_LOSS".
13. When I try to run "DBCC CHECKDB ...REPAIR_ALLOW_DATA_LOSS" in
this Single-Mode, it tells me "Could not run BEGIN TRANSACTION in
database 'MyDB' because the database is in bypass recovery mode."
I am stuck here. Could anyone here help, please?
I may have incorrectly listed down the sequence from point 8 to 11 but
my current status is at point 13.
Regards,
Garreth Goh
On Dec 18, 10:58 am, gohtiamt...@.gmail.com wrote:
> BTW, it is SQL 2000 with SP3.
> Regards,
> Garreth Goh|||The error pretty much speak for itself. My guess is that you have to try to export the data to a
clean database, using some combination of script objects (unless you have DDL files to re-create
them) and for the data SELECT INTO., INSERT SELECT, BCP etc.
I would bring in an expert if above doesn't feel comfortable to you...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<gohtiamtjai@.gmail.com> wrote in message
news:078e33bc-1d03-4d24-a65b-96367d382dde@.a35g2000prf.googlegroups.com...
> Hi,
> More updates after several attempts (with separate SQL server 2000
> SP4).
> 01. I move the MDF and LDF files to another folders. I have two MDF
> and two LDF files for one database.
> 02. I attach the same but blank backup database to my SQL server with
> a new database name.
> 03. Back it up.
> 04. Restore the backup with the original database name in the initial
> folder where the corrupted files were.
> 05. Detach the new restored (but empty) database.
> 06. Move the new created MDF and LDF files to another folder.
> 07. Copy the original corrupted MDF and LDF files back to the original
> folder.
> 08. Attach the database. Got "Suspect" message.
> 09. Update "sysdatabases" to set the database into Emergency Mode.
> 10. Attach the database back. I got Emergency Mode.
> 11. Run "DBCC CHECKDB WITH NO_INFOMSGS" tells me to do
> "REPAIR_ALLOW_DATA_LOSS".
> 12. Stop SQL services and run in Command Prompt "SQLSERVR -c -m" cause
> it tells me to have Single-User mode when trying to run "DBCC
> CHECKDB ...REPAIR_ALLOW_DATA_LOSS".
> 13. When I try to run "DBCC CHECKDB ...REPAIR_ALLOW_DATA_LOSS" in
> this Single-Mode, it tells me "Could not run BEGIN TRANSACTION in
> database 'MyDB' because the database is in bypass recovery mode."
> I am stuck here. Could anyone here help, please?
> I may have incorrectly listed down the sequence from point 8 to 11 but
> my current status is at point 13.
>
> Regards,
> Garreth Goh
>
> On Dec 18, 10:58 am, gohtiamt...@.gmail.com wrote:
>> BTW, it is SQL 2000 with SP3.
>> Regards,
>> Garreth Goh|||Or get Microsoft Technical Support on the phone.
--
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
kgboles a earthlink dt net
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:261F6FD2-B073-42F2-A218-B3B6AFE3750D@.microsoft.com...
> The error pretty much speak for itself. My guess is that you have to try
> to export the data to a clean database, using some combination of script
> objects (unless you have DDL files to re-create them) and for the data
> SELECT INTO., INSERT SELECT, BCP etc.
> I would bring in an expert if above doesn't feel comfortable to you...
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://sqlblog.com/blogs/tibor_karaszi
>
> <gohtiamtjai@.gmail.com> wrote in message
> news:078e33bc-1d03-4d24-a65b-96367d382dde@.a35g2000prf.googlegroups.com...
>> Hi,
>> More updates after several attempts (with separate SQL server 2000
>> SP4).
>> 01. I move the MDF and LDF files to another folders. I have two MDF
>> and two LDF files for one database.
>> 02. I attach the same but blank backup database to my SQL server with
>> a new database name.
>> 03. Back it up.
>> 04. Restore the backup with the original database name in the initial
>> folder where the corrupted files were.
>> 05. Detach the new restored (but empty) database.
>> 06. Move the new created MDF and LDF files to another folder.
>> 07. Copy the original corrupted MDF and LDF files back to the original
>> folder.
>> 08. Attach the database. Got "Suspect" message.
>> 09. Update "sysdatabases" to set the database into Emergency Mode.
>> 10. Attach the database back. I got Emergency Mode.
>> 11. Run "DBCC CHECKDB WITH NO_INFOMSGS" tells me to do
>> "REPAIR_ALLOW_DATA_LOSS".
>> 12. Stop SQL services and run in Command Prompt "SQLSERVR -c -m" cause
>> it tells me to have Single-User mode when trying to run "DBCC
>> CHECKDB ...REPAIR_ALLOW_DATA_LOSS".
>> 13. When I try to run "DBCC CHECKDB ...REPAIR_ALLOW_DATA_LOSS" in
>> this Single-Mode, it tells me "Could not run BEGIN TRANSACTION in
>> database 'MyDB' because the database is in bypass recovery mode."
>> I am stuck here. Could anyone here help, please?
>> I may have incorrectly listed down the sequence from point 8 to 11 but
>> my current status is at point 13.
>>
>> Regards,
>> Garreth Goh
>>
>> On Dec 18, 10:58 am, gohtiamt...@.gmail.com wrote:
>> BTW, it is SQL 2000 with SP3.
>> Regards,
>> Garreth Goh
>
Friday, February 24, 2012
Error trying to access the Report Manager
Hullo,
When i try to access report manager i get the following error.
Error
Get Online Help
Could someone help me out
Ronald
Hi Ronald-
Your report server cannot access it's server encryption key. This is your private encryption key used to store sensitive information (such as passwords and connection information). If you backed up your key, you should restore this key. If you do not have a backup you have two options. (1) You could try to reverse any recent changes you've made to the server settings (i.e. if you changed the service account user), or (2) if you don't care about your saved encrupted info, you can delete all encrypted content. This can be done through the Report Server Configuration Tool for 2005, or RSConfig.exe tool for 2000. (Note this won't delete any reports, only encrypted content)
Thanks, Jon (MSFT)
Friday, February 17, 2012
Error severity
I want to write this SQL script
--
create table table1(
ID_TABLE1 varchar(15) not null
constraint PK_TABLE1 primary key clustered
(ID_TABLE1)
)
IF @.@.ERROR <> 0
BEGIN
print 'Error create table1'
END
--
The problem is when there is a 'create error', the code
print 'Error ...' is not executed because the error's
severity is too high and the script stops.
Is it possible to trap the default error ? When there is a
create error, I want that's the @.@.error is initialized and
the test is executed.
Thanks in advance for your help
Antoine (F-Paris)
MSSQL 7 & MSSQL 2000If the error is severe enough it will stop the batch and you can not trap it
within the batch. You would have to check for the error where you call the
batch. If your using something like ADO, sql server will report an error
that you can see in the errors collection.
Andrew J. Kelly
SQL Server MVP
"Antoine C." <acazedev@.libertysurfXXX.fr> wrote in message
news:11da01c3df60$d4f02bf0$a401280a@.phx.gbl...
quote:|||
> Hi,
> I want to write this SQL script
> --
> create table table1(
> ID_TABLE1 varchar(15) not null
> constraint PK_TABLE1 primary key clustered
> (ID_TABLE1)
> )
> IF @.@.ERROR <> 0
> BEGIN
> print 'Error create table1'
> END
> --
> The problem is when there is a 'create error', the code
> print 'Error ...' is not executed because the error's
> severity is too high and the script stops.
> Is it possible to trap the default error ? When there is a
> create error, I want that's the @.@.error is initialized and
> the test is executed.
> Thanks in advance for your help
> Antoine (F-Paris)
> MSSQL 7 & MSSQL 2000
quote:
>--Original Message--
>If the error is severe enough it will stop the batch
> and you can not trap itwithin the batch.
> You would have to check for the error where you call the
>batch.
>--
Thank you for the quick answer Andrew.
Bye