Record Locks: application

Showing posts with label application. Show all posts

Friday, March 30, 2012

Recovery of database 'abcdef'...

Hi Everybody,
We have an web-based application which connects to MSSQL Database 2000 + SP3.
Few ASP jobs failed says "timedout error" while connecting to one of database 'abcdef'. The other similar jobs connects to other databases are running fine. The application is an Web-based Application. The Database Server is MSSQL 2000+SP3+Standard Editi
on. Replication has been configured from this server to the other similar database server. Type of Replication is Merge. This DB Server is having around 24 Databases.
The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC & Re-index Jobs runs for this DB Server every weekend.
The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory. It's a dedicated MSSQL Server.
We thought it's a resouce constraint, so we rebooted the Server. The Job was initiated, it ran well without any problem.
After the reboot, I checked the MSSQL ErrorLog, the following informational messgs. been registered.
************************************************** *****************************
2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0% complete (approximately 154 more seconds) (Phase 2 of 3).
2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3% complete (approximately 55 more seconds) (Phase 2 of 3).
2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11% complete (approximately 23 more seconds) (Phase 2 of 3).
2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30% complete (approximately 16 more seconds) (Phase 2 of 3).
2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760' to execute extended stored procedure 'sp_MSgetversion'.
2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74% complete (approximately 5 more seconds) (Phase 2 of 3).
2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97% complete (approximately 0 more seconds) (Phase 2 of 3).
2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more seconds) (Phase 2 of 3).
2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more seconds) (Phase 3 of 3).
2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is 100% complete (approximately 0 more seconds) (Phase 3 of 3).
2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database 'abcdef' (18).
2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database 'abcdef'(18)
************************************************** *****************************
The above mesgs didn't come for other databases. Can anybody tell why it displayed like this for database 'abcdef' and what it means,
"
Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more seconds) (Phase 2 of 3).
".
Is that database is in Corruption stage...
tks in advance,
vasum
I've seen this when a user killed the SQL Server service after attempting to
kill a transaction and giving up on the rollback operation.
When the service comes back up, it needs to do a lot of repair.
I suppose this could also happen if you trip on the power card, or something
like that.
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85584AE2-2D6B-4976-B32D-1ACA7B4F1915@.microsoft.com...
> Hi Everybody,
> We have an web-based application which connects to MSSQL Database 2000 +
> SP3.
> Few ASP jobs failed says "timedout error" while connecting to one of
> database 'abcdef'. The other similar jobs connects to other databases are
> running fine. The application is an Web-based Application. The Database
> Server is MSSQL 2000+SP3+Standard Edition. Replication has been configured
> from this server to the other similar database server. Type of Replication
> is Merge. This DB Server is having around 24 Databases.
> The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC &
> Re-index Jobs runs for this DB Server every weekend.
> The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory.
> It's a dedicated MSSQL Server.
> We thought it's a resouce constraint, so we rebooted the Server. The Job
> was initiated, it ran well without any problem.
> After the reboot, I checked the MSSQL ErrorLog, the following
> informational messgs. been registered.
> ************************************************** *****************************
> 2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0%
> complete (approximately 154 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3%
> complete (approximately 55 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11%
> complete (approximately 23 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30%
> complete (approximately 16 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760'
> to execute extended stored procedure 'sp_MSgetversion'.
> 2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74%
> complete (approximately 5 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97%
> complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99%
> complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99%
> complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is
> 100% complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database
> 'abcdef' (18).
> 2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database
> 'abcdef'(18)
> ************************************************** *****************************
> The above mesgs didn't come for other databases. Can anybody tell why it
> displayed like this for database 'abcdef' and what it means,
> "
> Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more
> seconds) (Phase 2 of 3).
> ".
> Is that database is in Corruption stage...
> tks in advance,
> vasum
|||Aaron is correct. These entries are from your database going through
transaction recovery. SQL has to walk through the transaction log from the
last checkpoint and roll transactions either forward or back depending on
their commit status. Some databases have very recent checkpoints or no long
running transactions so they recover very quickly. SQL will give progress
reports on recovery when it thinks the recovery will take a while. The
long-running transaction probably was the original cause of your timeout
errors. You can use DBCC OPENTRAN to determine if there is a long-running
transaction in a particular database. I suspect this is related to your
merge replication, but that is just a guess.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85584AE2-2D6B-4976-B32D-1ACA7B4F1915@.microsoft.com...
> Hi Everybody,
> We have an web-based application which connects to MSSQL Database 2000 +
SP3.
> Few ASP jobs failed says "timedout error" while connecting to one of
database 'abcdef'. The other similar jobs connects to other databases are
running fine. The application is an Web-based Application. The Database
Server is MSSQL 2000+SP3+Standard Edition. Replication has been configured
from this server to the other similar database server. Type of Replication
is Merge. This DB Server is having around 24 Databases.
> The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC &
Re-index Jobs runs for this DB Server every weekend.
> The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory.
It's a dedicated MSSQL Server.
> We thought it's a resouce constraint, so we rebooted the Server. The Job
was initiated, it ran well without any problem.
> After the reboot, I checked the MSSQL ErrorLog, the following
informational messgs. been registered.
>
************************************************** **************************
***
> 2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0%
complete (approximately 154 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3%
complete (approximately 55 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11%
complete (approximately 23 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30%
complete (approximately 16 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760'
to execute extended stored procedure 'sp_MSgetversion'.
> 2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74%
complete (approximately 5 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97%
complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99%
complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99%
complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is
100% complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database
'abcdef' (18).
> 2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database
'abcdef'(18)
>
************************************************** **************************
***
> The above mesgs didn't come for other databases. Can anybody tell why it
displayed like this for database 'abcdef' and what it means,
> "
> Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more
seconds) (Phase 2 of 3).
> ".
> Is that database is in Corruption stage...
> tks in advance,
> vasum
|||Thanks for the reply.
In this case, nobody has killed the SQL Server Service or removing the trip on the Power Card. Since it a very critical
server, only few people have access to the Server.
Apart from these problems any other problem which makes these mesg to display in the SQL Server Errorlog.
tks in advance,
vasum
|||If the transaction recovery not happened, will that database would have gone to corrupt state. what other implications expected if transaction recovery not happened.
tks in advance,
vasum
|||vasum
Did you mean that your transaction log file gets corrupted?
Perform RESTORE DATABASE with RECOVERY option
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:A69F9633-7198-4400-97DB-CD0F252E0F34@.microsoft.com...
> If the transaction recovery not happened, will that database would have
gone to corrupt state. what other implications expected if transaction
recovery not happened.
> tks in advance,
> vasum
|||No. I am saying that the 'Transaction log corrupted' in that database.
I am just asking what other problems are expected if the recovery of database not happened and which situtation make
the database server to display this kind of informational mesg.
vasum
|||Well, if your Transaction log corrupted during the recovery process you will
get an error and the database will be displayed in suspect mode. So you will
need to perfom restore database with recovery option or detach and the
reatach your database.
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85D59D9B-FB3E-4D0B-8C4D-A83EDD6A527C@.microsoft.com...
> No. I am saying that the 'Transaction log corrupted' in that database.
> I am just asking what other problems are expected if the recovery of
database not happened and which situtation make
> the database server to display this kind of informational mesg.
> vasum
|||Recovery is about transactional consistancy. Recovery is NOT about fixing
corruption. SQL runs recovery so that the transactional engine can bring
the database to a transactionally consistant state. Again, every database
is 'recovered' on SQL system startup. Some take very little time, some can
take a long time. I once had an 8 hour transaction crash the server (Older
version) and it took 8 hours to roll it back. Expensive lesson.
SQL will not allow you to access the database until the recovery process is
completed. If an underlying data file is corrupted, you will need to
restore according to your recovery plan. Exactly how you do this and how
much data is lost depends on your choice of recovery model and your backup
procedures.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:A69F9633-7198-4400-97DB-CD0F252E0F34@.microsoft.com...
> If the transaction recovery not happened, will that database would have
gone to corrupt state. what other implications expected if transaction
recovery not happened.
> tks in advance,
> vasum
|||So you mean to say it's normal kind of informational mesg. We can ignore this.
Why I raised this in forum is, out of 24 databases, only for this database this kind of informational mesgs. displayed and few jobs which connects to this database were also failed saying "timedout error" but at the time users able to connect to this data
base through isqlw and do queries...I think this could be also the reason, Merge Replication is happening in that database as I said earlier. Before server reboot, we didn't stop the merge agents and we went for reboot. At the time some transaction would
have been published to the subscriber. May be this could also made this type of informational mesgs. to display in the errorlog. But same thing should happen to other databases also, right
"
2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0% complete (approximately 154 more seconds) (Phase 2 of 3).
- - -
- - -
2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more seconds) (Phase 3 of 3).
2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is 100% complete (approximately 0 more seconds) (Phase 3 of 3).
"
Pls. correct me if I am wrong...
vasum

Recovery of database 'abcdef'...

Hi Everybody,
We have an web-based application which connects to MSSQL Database 2000 + SP3
.
Few ASP jobs failed says "timedout error" while connecting to one of databas
e 'abcdef'. The other similar jobs connects to other databases are running
fine. The application is an Web-based Application. The Database Server is MS
SQL 2000+SP3+Standard Editi
on. Replication has been configured from this server to the other similar da
tabase server. Type of Replication is Merge. This DB Server is having around
24 Databases.
The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC & R
e-index Jobs runs for this DB Server every weekend.
The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory. I
t's a dedicated MSSQL Server.
We thought it's a resouce constraint, so we rebooted the Server. The Job was
initiated, it ran well without any problem.
After the reboot, I checked the MSSQL ErrorLog, the following informational
messgs. been registered.
****************************************
************************************
***
2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0% co
mplete (approximately 154 more seconds) (Phase 2 of 3).
2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3% co
mplete (approximately 55 more seconds) (Phase 2 of 3).
2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11% co
mplete (approximately 23 more seconds) (Phase 2 of 3).
2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30% c
omplete (approximately 16 more seconds) (Phase 2 of 3).
2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760' to
execute extended stored procedure 'sp_MSgetversion'.
2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74% c
omplete (approximately 5 more seconds) (Phase 2 of 3).
2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97% c
omplete (approximately 0 more seconds) (Phase 2 of 3).
2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99% c
omplete (approximately 0 more seconds) (Phase 2 of 3).
2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99% c
omplete (approximately 0 more seconds) (Phase 3 of 3).
2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is 100%
complete (approximately 0 more seconds) (Phase 3 of 3).
2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database 'abc
def' (18).
2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database 'abcdef'
(18)
****************************************
************************************
***
The above mesgs didn't come for other databases. Can anybody tell why it dis
played like this for database 'abcdef' and what it means,
"
Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more sec
onds) (Phase 2 of 3).
".
Is that database is in Corruption stage...
tks in advance,
vasumI've seen this when a user killed the SQL Server service after attempting to
kill a transaction and giving up on the rollback operation.
When the service comes back up, it needs to do a lot of repair.
I suppose this could also happen if you trip on the power card, or something
like that.
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85584AE2-2D6B-4976-B32D-1ACA7B4F1915@.microsoft.com...
> Hi Everybody,
> We have an web-based application which connects to MSSQL Database 2000 +
> SP3.
> Few ASP jobs failed says "timedout error" while connecting to one of
> database 'abcdef'. The other similar jobs connects to other databases are
> running fine. The application is an Web-based Application. The Database
> Server is MSSQL 2000+SP3+Standard Edition. Replication has been configured
> from this server to the other similar database server. Type of Replication
> is Merge. This DB Server is having around 24 Databases.
> The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC &
> Re-index Jobs runs for this DB Server every weekend.
> The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory.
> It's a dedicated MSSQL Server.
> We thought it's a resouce constraint, so we rebooted the Server. The Job
> was initiated, it ran well without any problem.
> After the reboot, I checked the MSSQL ErrorLog, the following
> informational messgs. been registered.
> ****************************************
**********************************
*****
> 2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0%
> complete (approximately 154 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3%
> complete (approximately 55 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11%
> complete (approximately 23 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30%
> complete (approximately 16 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760'
> to execute extended stored procedure 'sp_MSgetversion'.
> 2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74%
> complete (approximately 5 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97%
> complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99%
> complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99%
> complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is
> 100% complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database
> 'abcdef' (18).
> 2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database
> 'abcdef'(18)
> ****************************************
**********************************
*****
> The above mesgs didn't come for other databases. Can anybody tell why it
> displayed like this for database 'abcdef' and what it means,
> "
> Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more
> seconds) (Phase 2 of 3).
> ".
> Is that database is in Corruption stage...
> tks in advance,
> vasum|||Aaron is correct. These entries are from your database going through
transaction recovery. SQL has to walk through the transaction log from the
last checkpoint and roll transactions either forward or back depending on
their commit status. Some databases have very recent checkpoints or no long
running transactions so they recover very quickly. SQL will give progress
reports on recovery when it thinks the recovery will take a while. The
long-running transaction probably was the original cause of your timeout
errors. You can use DBCC OPENTRAN to determine if there is a long-running
transaction in a particular database. I suspect this is related to your
merge replication, but that is just a guess.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85584AE2-2D6B-4976-B32D-1ACA7B4F1915@.microsoft.com...
> Hi Everybody,
> We have an web-based application which connects to MSSQL Database 2000 +
SP3.
> Few ASP jobs failed says "timedout error" while connecting to one of
database 'abcdef'. The other similar jobs connects to other databases are
running fine. The application is an Web-based Application. The Database
Server is MSSQL 2000+SP3+Standard Edition. Replication has been configured
from this server to the other similar database server. Type of Replication
is Merge. This DB Server is having around 24 Databases.
> The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC &
Re-index Jobs runs for this DB Server every weekend.
> The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory.
It's a dedicated MSSQL Server.
> We thought it's a resouce constraint, so we rebooted the Server. The Job
was initiated, it ran well without any problem.
> After the reboot, I checked the MSSQL ErrorLog, the following
informational messgs. been registered.
>
****************************************
************************************
***
> 2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0%
complete (approximately 154 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3%
complete (approximately 55 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11%
complete (approximately 23 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30%
complete (approximately 16 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760'
to execute extended stored procedure 'sp_MSgetversion'.
> 2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74%
complete (approximately 5 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97%
complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99%
complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99%
complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is
100% complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database
'abcdef' (18).
> 2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database
'abcdef'(18)
>
****************************************
************************************
***
> The above mesgs didn't come for other databases. Can anybody tell why it
displayed like this for database 'abcdef' and what it means,
> "
> Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more
seconds) (Phase 2 of 3).
> ".
> Is that database is in Corruption stage...
> tks in advance,
> vasum|||Thanks for the reply.
In this case, nobody has killed the SQL Server Service or removing the trip
on the Power Card. Since it a very critical
server, only few people have access to the Server.
Apart from these problems any other problem which makes these mesg to displa
y in the SQL Server Errorlog.
tks in advance,
vasum|||If the transaction recovery not happened, will that database would have gone
to corrupt state. what other implications expected if transaction recovery
not happened.
tks in advance,
vasum|||vasum
Did you mean that your transaction log file gets corrupted?
Perform RESTORE DATABASE with RECOVERY option
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:A69F9633-7198-4400-97DB-CD0F252E0F34@.microsoft.com...
> If the transaction recovery not happened, will that database would have
gone to corrupt state. what other implications expected if transaction
recovery not happened.
> tks in advance,
> vasum|||No. I am saying that the 'Transaction log corrupted' in that database.
I am just asking what other problems are expected if the recovery of databas
e not happened and which situtation make
the database server to display this kind of informational mesg.
vasum|||Well, if your Transaction log corrupted during the recovery process you will
get an error and the database will be displayed in suspect mode. So you will
need to perfom restore database with recovery option or detach and the
reatach your database.
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85D59D9B-FB3E-4D0B-8C4D-A83EDD6A527C@.microsoft.com...
> No. I am saying that the 'Transaction log corrupted' in that database.
> I am just asking what other problems are expected if the recovery of
database not happened and which situtation make
> the database server to display this kind of informational mesg.
> vasum|||Recovery is about transactional consistancy. Recovery is NOT about fixing
corruption. SQL runs recovery so that the transactional engine can bring
the database to a transactionally consistant state. Again, every database
is 'recovered' on SQL system startup. Some take very little time, some can
take a long time. I once had an 8 hour transaction crash the server (Older
version) and it took 8 hours to roll it back. Expensive lesson.
SQL will not allow you to access the database until the recovery process is
completed. If an underlying data file is corrupted, you will need to
restore according to your recovery plan. Exactly how you do this and how
much data is lost depends on your choice of recovery model and your backup
procedures.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:A69F9633-7198-4400-97DB-CD0F252E0F34@.microsoft.com...
> If the transaction recovery not happened, will that database would have
gone to corrupt state. what other implications expected if transaction
recovery not happened.
> tks in advance,
> vasum|||So you mean to say it's normal kind of informational mesg. We can ignore thi
s.
Why I raised this in forum is, out of 24 databases, only for this database t
his kind of informational mesgs. displayed and few jobs which connects to th
is database were also failed saying "timedout error" but at the time users a
ble to connect to this data
base through isqlw and do queries...I think this could be also the reason,
Merge Replication is happening in that database as I said earlier. Before se
rver reboot, we didn't stop the merge agents and we went for reboot. At the
time some transaction would
have been published to the subscriber. May be this could also made this type
of informational mesgs. to display in the errorlog. But same thing should h
appen to other databases also, right
"
2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0% co
mplete (approximately 154 more seconds) (Phase 2 of 3).
- - -
- - -
2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99% c
omplete (approximately 0 more seconds) (Phase 3 of 3).
2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is 100%
complete (approximately 0 more seconds) (Phase 3 of 3).
"
Pls. correct me if I am wrong...
vasum

Recovery of database 'abcdef'...

Hi Everybody
We have an web-based application which connects to MSSQL Database 2000 + SP3
Few ASP jobs failed says "timedout error" while connecting to one of database 'abcdef'. The other similar jobs connects to other databases are running fine. The application is an Web-based Application. The Database Server is MSSQL 2000+SP3+Standard Edition. Replication has been configured from this server to the other similar database server. Type of Replication is Merge. This DB Server is having around 24 Databases.
The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC & Re-index Jobs runs for this DB Server every weekend
The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory. It's a dedicated MSSQL Server
We thought it's a resouce constraint, so we rebooted the Server. The Job was initiated, it ran well without any problem
After the reboot, I checked the MSSQL ErrorLog, the following informational messgs. been registered.
******************************************************************************
2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0% complete (approximately 154 more seconds) (Phase 2 of 3)
2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3% complete (approximately 55 more seconds) (Phase 2 of 3)
2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11% complete (approximately 23 more seconds) (Phase 2 of 3)
2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30% complete (approximately 16 more seconds) (Phase 2 of 3)
2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760' to execute extended stored procedure 'sp_MSgetversion'
2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74% complete (approximately 5 more seconds) (Phase 2 of 3)
2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97% complete (approximately 0 more seconds) (Phase 2 of 3)
2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more seconds) (Phase 2 of 3)
2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more seconds) (Phase 3 of 3)
2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is 100% complete (approximately 0 more seconds) (Phase 3 of 3)
2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database 'abcdef' (18)
2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database 'abcdef'(18
******************************************************************************
The above mesgs didn't come for other databases. Can anybody tell why it displayed like this for database 'abcdef' and what it means
Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more seconds) (Phase 2 of 3).
"
Is that database is in Corruption stage..
tks in advance
vasumI've seen this when a user killed the SQL Server service after attempting to
kill a transaction and giving up on the rollback operation.
When the service comes back up, it needs to do a lot of repair.
I suppose this could also happen if you trip on the power card, or something
like that.
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85584AE2-2D6B-4976-B32D-1ACA7B4F1915@.microsoft.com...
> Hi Everybody,
> We have an web-based application which connects to MSSQL Database 2000 +
> SP3.
> Few ASP jobs failed says "timedout error" while connecting to one of
> database 'abcdef'. The other similar jobs connects to other databases are
> running fine. The application is an Web-based Application. The Database
> Server is MSSQL 2000+SP3+Standard Edition. Replication has been configured
> from this server to the other similar database server. Type of Replication
> is Merge. This DB Server is having around 24 Databases.
> The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC &
> Re-index Jobs runs for this DB Server every weekend.
> The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory.
> It's a dedicated MSSQL Server.
> We thought it's a resouce constraint, so we rebooted the Server. The Job
> was initiated, it ran well without any problem.
> After the reboot, I checked the MSSQL ErrorLog, the following
> informational messgs. been registered.
> *******************************************************************************
> 2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0%
> complete (approximately 154 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3%
> complete (approximately 55 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11%
> complete (approximately 23 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30%
> complete (approximately 16 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760'
> to execute extended stored procedure 'sp_MSgetversion'.
> 2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74%
> complete (approximately 5 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97%
> complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99%
> complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99%
> complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is
> 100% complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database
> 'abcdef' (18).
> 2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database
> 'abcdef'(18)
> *******************************************************************************
> The above mesgs didn't come for other databases. Can anybody tell why it
> displayed like this for database 'abcdef' and what it means,
> "
> Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more
> seconds) (Phase 2 of 3).
> ".
> Is that database is in Corruption stage...
> tks in advance,
> vasum|||Aaron is correct. These entries are from your database going through
transaction recovery. SQL has to walk through the transaction log from the
last checkpoint and roll transactions either forward or back depending on
their commit status. Some databases have very recent checkpoints or no long
running transactions so they recover very quickly. SQL will give progress
reports on recovery when it thinks the recovery will take a while. The
long-running transaction probably was the original cause of your timeout
errors. You can use DBCC OPENTRAN to determine if there is a long-running
transaction in a particular database. I suspect this is related to your
merge replication, but that is just a guess.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85584AE2-2D6B-4976-B32D-1ACA7B4F1915@.microsoft.com...
> Hi Everybody,
> We have an web-based application which connects to MSSQL Database 2000 +
SP3.
> Few ASP jobs failed says "timedout error" while connecting to one of
database 'abcdef'. The other similar jobs connects to other databases are
running fine. The application is an Web-based Application. The Database
Server is MSSQL 2000+SP3+Standard Edition. Replication has been configured
from this server to the other similar database server. Type of Replication
is Merge. This DB Server is having around 24 Databases.
> The database size of 'abcdef' is 1200 MB (Data 850 MB, Log 400 MB). DBCC &
Re-index Jobs runs for this DB Server every weekend.
> The OS for this DB server is Windows advanced Server + 4CPU + 2 GB Memory.
It's a dedicated MSSQL Server.
> We thought it's a resouce constraint, so we rebooted the Server. The Job
was initiated, it ran well without any problem.
> After the reboot, I checked the MSSQL ErrorLog, the following
informational messgs. been registered.
>
****************************************************************************
***
> 2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0%
complete (approximately 154 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.02 spid21 Recovery of database 'abcdef' (18) is 3%
complete (approximately 55 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:58.24 spid21 Recovery of database 'abcdef'(18) is 11%
complete (approximately 23 more seconds) (Phase 2 of 3).
> 2004-04-28 15:28:59.90 spid21 Recovery of database 'abcdef' (18) is 30%
complete (approximately 16 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:01.14 spid55 Using 'xpstar.dll' version '2000.80.760'
to execute extended stored procedure 'sp_MSgetversion'.
> 2004-04-28 15:29:01.45 spid21 Recovery of database 'abcdef' (18) is 74%
complete (approximately 5 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.01 spid21 Recovery of database 'abcdef' (18) is 97%
complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.41 spid21 Recovery of database 'abcdef' (18) is 99%
complete (approximately 0 more seconds) (Phase 2 of 3).
> 2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99%
complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is
100% complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 1 transactions rolled back in database
'abcdef' (18).
> 2004-04-28 15:29:06.80 spid21 Recovery is checkpointing database
'abcdef'(18)
>
****************************************************************************
***
> The above mesgs didn't come for other databases. Can anybody tell why it
displayed like this for database 'abcdef' and what it means,
> "
> Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more
seconds) (Phase 2 of 3).
> ".
> Is that database is in Corruption stage...
> tks in advance,
> vasum|||Thanks for the reply
In this case, nobody has killed the SQL Server Service or removing the trip on the Power Card. Since it a very critica
server, only few people have access to the Server
Apart from these problems any other problem which makes these mesg to display in the SQL Server Errorlog
tks in advance
vasum|||If the transaction recovery not happened, will that database would have gone to corrupt state. what other implications expected if transaction recovery not happened
tks in advance
vasum|||vasum
Did you mean that your transaction log file gets corrupted?
Perform RESTORE DATABASE with RECOVERY option
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:A69F9633-7198-4400-97DB-CD0F252E0F34@.microsoft.com...
> If the transaction recovery not happened, will that database would have
gone to corrupt state. what other implications expected if transaction
recovery not happened.
> tks in advance,
> vasum|||No. I am saying that the 'Transaction log corrupted' in that database
I am just asking what other problems are expected if the recovery of database not happened and which situtation mak
the database server to display this kind of informational mesg
vasum|||Well, if your Transaction log corrupted during the recovery process you will
get an error and the database will be displayed in suspect mode. So you will
need to perfom restore database with recovery option or detach and the
reatach your database.
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:85D59D9B-FB3E-4D0B-8C4D-A83EDD6A527C@.microsoft.com...
> No. I am saying that the 'Transaction log corrupted' in that database.
> I am just asking what other problems are expected if the recovery of
database not happened and which situtation make
> the database server to display this kind of informational mesg.
> vasum|||Recovery is about transactional consistancy. Recovery is NOT about fixing
corruption. SQL runs recovery so that the transactional engine can bring
the database to a transactionally consistant state. Again, every database
is 'recovered' on SQL system startup. Some take very little time, some can
take a long time. I once had an 8 hour transaction crash the server (Older
version) and it took 8 hours to roll it back. Expensive lesson.
SQL will not allow you to access the database until the recovery process is
completed. If an underlying data file is corrupted, you will need to
restore according to your recovery plan. Exactly how you do this and how
much data is lost depends on your choice of recovery model and your backup
procedures.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:A69F9633-7198-4400-97DB-CD0F252E0F34@.microsoft.com...
> If the transaction recovery not happened, will that database would have
gone to corrupt state. what other implications expected if transaction
recovery not happened.
> tks in advance,
> vasum|||So you mean to say it's normal kind of informational mesg. We can ignore this
Why I raised this in forum is, out of 24 databases, only for this database this kind of informational mesgs. displayed and few jobs which connects to this database were also failed saying "timedout error" but at the time users able to connect to this database through isqlw and do queries...I think this could be also the reason, Merge Replication is happening in that database as I said earlier. Before server reboot, we didn't stop the merge agents and we went for reboot. At the time some transaction would have been published to the subscriber. May be this could also made this type of informational mesgs. to display in the errorlog. But same thing should happen to other databases also, right
2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0% complete (approximately 154 more seconds) (Phase 2 of 3)
- - -
- -
2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99% complete (approximately 0 more seconds) (Phase 3 of 3)
2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is 100% complete (approximately 0 more seconds) (Phase 3 of 3)
Pls. correct me if I am wrong...
vasum|||It depends.
Recovery is related to the number and size of open transactions and
uncommitted data in the database. If the database was checkpointed
immediately before the shutdown and didn't have any long-running
transactions, then the recovery will be short. SQL can estimate the amount
of work to be done and will update the event log as necessary. Read the
following topic in BOL for the details on how this process really works.
SQL Server Architecture | Relational Database Engine Architecture |
Transactions Architecture | Transaction Recovery.
For some reason, Transaction Recovery isn't in the index so you have to find
this through Contents.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"vasum" <anonymous@.discussions.microsoft.com> wrote in message
news:3AD49B0F-7185-4D3A-B78B-B54CAB861999@.microsoft.com...
> So you mean to say it's normal kind of informational mesg. We can ignore
this.
> Why I raised this in forum is, out of 24 databases, only for this database
this kind of informational mesgs. displayed and few jobs which connects to
this database were also failed saying "timedout error" but at the time users
able to connect to this database through isqlw and do queries...I think
this could be also the reason, Merge Replication is happening in that
database as I said earlier. Before server reboot, we didn't stop the merge
agents and we went for reboot. At the time some transaction would have been
published to the subscriber. May be this could also made this type of
informational mesgs. to display in the errorlog. But same thing should
happen to other databases also, right
> "
> 2004-04-28 15:28:57.85 spid21 Recovery of database 'abcdef' (18) is 0%
complete (approximately 154 more seconds) (Phase 2 of 3).
> - - -
> - - -
> 2004-04-28 15:29:06.46 spid21 Recovery of database 'abcdef' (18) is 99%
complete (approximately 0 more seconds) (Phase 3 of 3).
> 2004-04-28 15:29:06.79 spid21 Recovery of database 'abcdef' (18) is
100% complete (approximately 0 more seconds) (Phase 3 of 3).
> "
> Pls. correct me if I am wrong...
> vasum

Recovery of database

By mistake I deleted the my application database, and I dont have Back up
also...
is there any way to recover it...
Please help me.. its very urgent
Regards,
Prashant C
Oops, no backups!!!
Then its gone...
Thanks,
Sree
[Please specify the version of Sql Server as we can save one thread and time
asking back if its 2000 or 2005]
"Prashant C" wrote:

> By mistake I deleted the my application database, and I dont have Back up
> also...
> is there any way to recover it...
>
> Please help me.. its very urgent
> --
> Regards,
> Prashant C
|||Unless some Widows utility can recovery the deleted database files. If so, you could try
sp_attach_db for the files, but that is not guaranteed.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Sreejith G" <SreejithG@.discussions.microsoft.com> wrote in message
news:050D39A3-1771-46C4-A3A2-79E016B1E150@.microsoft.com...[vbcol=seagreen]
> Oops, no backups!!!
> Then its gone...
> --
> Thanks,
> Sree
> [Please specify the version of Sql Server as we can save one thread and time
> asking back if its 2000 or 2005]
>
> "Prashant C" wrote:
sql

Recovery of database

By mistake I deleted the my application database, and I dont have Back up
also...
is there any way to recover it...
Please help me.. its very urgent
--
Regards,
Prashant COops, no backups!!!
Then its gone...
--
Thanks,
Sree
[Please specify the version of Sql Server as we can save one thread and
time
asking back if its 2000 or 2005]
"Prashant C" wrote:

> By mistake I deleted the my application database, and I dont have Back up
> also...
> is there any way to recover it...
>
> Please help me.. its very urgent
> --
> Regards,
> Prashant C|||Unless some Widows utility can recovery the deleted database files. If so, y
ou could try
sp_attach_db for the files, but that is not guaranteed.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Sreejith G" <SreejithG@.discussions.microsoft.com> wrote in message
news:050D39A3-1771-46C4-A3A2-79E016B1E150@.microsoft.com...[vbcol=seagreen]
> Oops, no backups!!!
> Then its gone...
> --
> Thanks,
> Sree
> [Please specify the version of Sql Server as we can save one thread an
d time
> asking back if its 2000 or 2005]
>
> "Prashant C" wrote:
>

Recovery of database

By mistake I deleted the my application database, and I dont have Back up
also...
is there any way to recover it...
Please help me.. its very urgent
--
Regards,
Prashant COops, no backups!!!
Then its gone...
--
Thanks,
Sree
[Please specify the version of Sql Server as we can save one thread and time
asking back if its 2000 or 2005]
"Prashant C" wrote:
> By mistake I deleted the my application database, and I dont have Back up
> also...
> is there any way to recover it...
>
> Please help me.. its very urgent
> --
> Regards,
> Prashant C|||Unless some Widows utility can recovery the deleted database files. If so, you could try
sp_attach_db for the files, but that is not guaranteed.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Sreejith G" <SreejithG@.discussions.microsoft.com> wrote in message
news:050D39A3-1771-46C4-A3A2-79E016B1E150@.microsoft.com...
> Oops, no backups!!!
> Then its gone...
> --
> Thanks,
> Sree
> [Please specify the version of Sql Server as we can save one thread and time
> asking back if its 2000 or 2005]
>
> "Prashant C" wrote:
>> By mistake I deleted the my application database, and I dont have Back up
>> also...
>> is there any way to recover it...
>>
>> Please help me.. its very urgent
>> --
>> Regards,
>> Prashant C

Friday, March 23, 2012

Recovering from Deadlocks: retrying the query

I'm having some deadlocking issues in my ASP.Net 2.0 web application with SQL Server 2000. One solution I've come across involves catching the the deadlock error (at the application level) and then retrying the query again, in the hopes that whatever was causing the deadlock is no longer locked.

I've tried to implement such a solution, where I catch the deadlock exception, then try to execute the same query again. Only now I'm getting a "The transaction is in doubt" exception.

So am I going about this wrong? Am I supposed to retry the entire transaction, or is valid to just try to redo the one query that it failed on? Is there some way around the transaction being in doubt?

You should determine the cause of the deadlock and correct your SQL code rather than retry mechanism. Retry mechanism can be complicated depending on what you are doing, whether you are in a transaction and so on. Deadlock typically means that you have access paths in your code that is not optimized and different for similar operations. Check out the following links on how to troubleshoot deadlocks:

http://msdn2.microsoft.com/en-us/library/ms177433.aspx

http://msdn2.microsoft.com/en-us/library/ms188246.aspx

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_con_7a_8i93.asp

sql

Tuesday, March 20, 2012

Recover SDF-File

Hi,

we're using SQL Server CE 2.0 on our CE 4.2 device (mobile scanning device).
In some cases, the application freezes and the user must perfom a cold boot.

After the cold boot, the database is some kind of corrupt - the application can't build up a new connection and a "Fatal Applicatio Error ...." is thrown.

If you try to connect to that SDF-File via the Query Analyser Tool, it also throws an exception .... "DBInitiliaze"....

Do have anyone an idea whats wrong with the SDF-File and more important: How could we recover such files - most times there is already business data stored, which would be than lost...

Thanks
WilliBaldDid you try compacting the SQL CE 2.0 database.

Thanks,
Laxmi|||Hi,

sorry - I can't follow you - what do you mean with "compacting"?

I fare as I understand, the SQL Server CE 2.0 database stores its data in such *.sdf files and I'm not aware, that we compress or compact them in any way - the problem is, that if the application freezes when you perform a database action, the database falls in some stage, where you even can't connect with the QueryAnalyzer - as if the *.sdf file is still open...

Thanks
WilliBald|||

There could be an option in ISQLW tool before connecting to a database do "Repair & Connect".

Thanks,
Laxmi NRO, MSFT, SQL Mobile, Microsoft Corporation

|||The easiest way to kick off a Compact on an .sdf file is to use the
"SQLCE Database Viewer" tool.

Aswell as letting you view & edit your SQLCE2.0 and SQL Server Mobile
databases from your Desktop, this has a friendly ActiveSync Explorer
style front-end, and you can literally right-click on an .sdf file, and
select "Compact.."

You don't have to tap on your device's screen once !
It doesn't get much easier than that...

www.pocketpctoolkit.com
Mike
|||WilliBald,

With SQL CE 2.0, the only option available to attempt to repair a database is to call Compact on the SqlCeEngine object. Compact verifies database integrity, reclaims unused space, recalculates index statistics, etc. Unfortunately, if you cannot Compact the database, there is little else you can do to recover it. With SQL Mobile, this improves with the addition of Verify and Repair options on the database engine.

In most cases, SQL CE databases that I have seen become corrupted are on storage cards or other removable storage.

-Darren Shaffer|||Hi Mike,

thanks VERY much!
The tool is great and I've managed to restore the database files!

One more question: Is there a chance to get the mobile binaries also for SH4 processor? - Cause we have devices with that typ of cpu.

regads
willibald|||

hello Mike,

I read your answer and i download the same viewer and its really helpful. But still i am not able to compact my database. whenever i use compact database option it keep trying and doing nothing at the end. Even i wrote my own application to do so using Data.engin etc, but still unable to recover my database .SDF file.

Kindly tell me is there any clue to rectify this ?

Thanks in advance

|||

I have had the same problem with a corrupt SDF file.

All I did was Compact it.

Encrypt it again.

All works fine.

Recover SDF-File

Hi,

we're using SQL Server CE 2.0 on our CE 4.2 device (mobile scanning device).
In some cases, the application freezes and the user must perfom a cold boot.

After the cold boot, the database is some kind of corrupt - the application can't build up a new connection and a "Fatal Applicatio Error ...." is thrown.

If you try to connect to that SDF-File via the Query Analyser Tool, it also throws an exception .... "DBInitiliaze"....

Do have anyone an idea whats wrong with the SDF-File and more important: How could we recover such files - most times there is already business data stored, which would be than lost...

Thanks
WilliBaldDid you try compacting the SQL CE 2.0 database.

Thanks,
Laxmi|||Hi,

sorry - I can't follow you - what do you mean with "compacting"?

Thanks
WilliBald|||

There could be an option in ISQLW tool before connecting to a database do "Repair & Connect".

Thanks,
Laxmi NRO, MSFT, SQL Mobile, Microsoft Corporation

|||The easiest way to kick off a Compact on an .sdf file is to use the
"SQLCE Database Viewer" tool.

You don't have to tap on your device's screen once !
It doesn't get much easier than that...

www.pocketpctoolkit.com
Mike
|||WilliBald,

In most cases, SQL CE databases that I have seen become corrupted are on storage cards or other removable storage.

-Darren Shaffer|||Hi Mike,

thanks VERY much!
The tool is great and I've managed to restore the database files!

One more question: Is there a chance to get the mobile binaries also for SH4 processor? - Cause we have devices with that typ of cpu.

regads
willibald|||

hello Mike,

Kindly tell me is there any clue to rectify this ?

Thanks in advance

|||

I have had the same problem with a corrupt SDF file.

All I did was Compact it.

Encrypt it again.

All works fine.

|||As file incourrpt , if the sdf is corrupt , could repair this file is very lucky.

Try to use SqlCeEngine .Repaire method. if failure, reCreate the sdf maybe is the only way .

Recover SDF-File

Hi,

we're using SQL Server CE 2.0 on our CE 4.2 device (mobile scanning device).
In some cases, the application freezes and the user must perfom a cold boot.

After the cold boot, the database is some kind of corrupt - the application can't build up a new connection and a "Fatal Applicatio Error ...." is thrown.

If you try to connect to that SDF-File via the Query Analyser Tool, it also throws an exception .... "DBInitiliaze"....

Do have anyone an idea whats wrong with the SDF-File and more important: How could we recover such files - most times there is already business data stored, which would be than lost...

Thanks
WilliBaldDid you try compacting the SQL CE 2.0 database.

Thanks,
Laxmi|||Hi,

sorry - I can't follow you - what do you mean with "compacting"?

Thanks
WilliBald|||

There could be an option in ISQLW tool before connecting to a database do "Repair & Connect".

Thanks,
Laxmi NRO, MSFT, SQL Mobile, Microsoft Corporation

|||The easiest way to kick off a Compact on an .sdf file is to use the
"SQLCE Database Viewer" tool.

You don't have to tap on your device's screen once !
It doesn't get much easier than that...

www.pocketpctoolkit.com
Mike
|||WilliBald,

In most cases, SQL CE databases that I have seen become corrupted are on storage cards or other removable storage.

-Darren Shaffer|||Hi Mike,

thanks VERY much!
The tool is great and I've managed to restore the database files!

One more question: Is there a chance to get the mobile binaries also for SH4 processor? - Cause we have devices with that typ of cpu.

regads
willibald|||

hello Mike,

Kindly tell me is there any clue to rectify this ?

Thanks in advance

|||

I have had the same problem with a corrupt SDF file.

All I did was Compact it.

Encrypt it again.

All works fine.

|||As file incourrpt , if the sdf is corrupt , could repair this file is very lucky.

Try to use SqlCeEngine .Repaire method. if failure, reCreate the sdf maybe is the only way .

Recover SDF-File

Hi,

we're using SQL Server CE 2.0 on our CE 4.2 device (mobile scanning device).
In some cases, the application freezes and the user must perfom a cold boot.

After the cold boot, the database is some kind of corrupt - the application can't build up a new connection and a "Fatal Applicatio Error ...." is thrown.

If you try to connect to that SDF-File via the Query Analyser Tool, it also throws an exception .... "DBInitiliaze"....

Do have anyone an idea whats wrong with the SDF-File and more important: How could we recover such files - most times there is already business data stored, which would be than lost...

Thanks
WilliBaldDid you try compacting the SQL CE 2.0 database.

Thanks,
Laxmi|||Hi,

sorry - I can't follow you - what do you mean with "compacting"?

Thanks
WilliBald|||

There could be an option in ISQLW tool before connecting to a database do "Repair & Connect".

Thanks,
Laxmi NRO, MSFT, SQL Mobile, Microsoft Corporation

|||The easiest way to kick off a Compact on an .sdf file is to use the
"SQLCE Database Viewer" tool.

You don't have to tap on your device's screen once !
It doesn't get much easier than that...

www.pocketpctoolkit.com
Mike
|||WilliBald,

In most cases, SQL CE databases that I have seen become corrupted are on storage cards or other removable storage.

-Darren Shaffer|||Hi Mike,

thanks VERY much!
The tool is great and I've managed to restore the database files!

One more question: Is there a chance to get the mobile binaries also for SH4 processor? - Cause we have devices with that typ of cpu.

regads
willibald|||

hello Mike,

Kindly tell me is there any clue to rectify this ?

Thanks in advance

|||

I have had the same problem with a corrupt SDF file.

All I did was Compact it.

Encrypt it again.

All works fine.

Recover SDF-File

Hi,

we're using SQL Server CE 2.0 on our CE 4.2 device (mobile scanning device).
In some cases, the application freezes and the user must perfom a cold boot.

After the cold boot, the database is some kind of corrupt - the application can't build up a new connection and a "Fatal Applicatio Error ...." is thrown.

If you try to connect to that SDF-File via the Query Analyser Tool, it also throws an exception .... "DBInitiliaze"....

Do have anyone an idea whats wrong with the SDF-File and more important: How could we recover such files - most times there is already business data stored, which would be than lost...

Thanks
WilliBaldDid you try compacting the SQL CE 2.0 database.

Thanks,
Laxmi|||Hi,

sorry - I can't follow you - what do you mean with "compacting"?

Thanks
WilliBald|||

There could be an option in ISQLW tool before connecting to a database do "Repair & Connect".

Thanks,
Laxmi NRO, MSFT, SQL Mobile, Microsoft Corporation

|||The easiest way to kick off a Compact on an .sdf file is to use the
"SQLCE Database Viewer" tool.

You don't have to tap on your device's screen once !
It doesn't get much easier than that...

www.pocketpctoolkit.com
Mike|||WilliBald,

In most cases, SQL CE databases that I have seen become corrupted are on storage cards or other removable storage.

-Darren Shaffer|||Hi Mike,

thanks VERY much!
The tool is great and I've managed to restore the database files!

One more question: Is there a chance to get the mobile binaries also for SH4 processor? - Cause we have devices with that typ of cpu.

regads
willibald|||

hello Mike,

Kindly tell me is there any clue to rectify this ?

Thanks in advance

|||

I have had the same problem with a corrupt SDF file.

All I did was Compact it.

Encrypt it again.

All works fine.

Recover SDF-File

Hi,

we're using SQL Server CE 2.0 on our CE 4.2 device (mobile scanning device).
In some cases, the application freezes and the user must perfom a cold boot.

After the cold boot, the database is some kind of corrupt - the application can't build up a new connection and a "Fatal Applicatio Error ...." is thrown.

If you try to connect to that SDF-File via the Query Analyser Tool, it also throws an exception .... "DBInitiliaze"....

Do have anyone an idea whats wrong with the SDF-File and more important: How could we recover such files - most times there is already business data stored, which would be than lost...

Thanks
WilliBaldDid you try compacting the SQL CE 2.0 database.

Thanks,
Laxmi|||Hi,

sorry - I can't follow you - what do you mean with "compacting"?

Thanks
WilliBald|||

There could be an option in ISQLW tool before connecting to a database do "Repair & Connect".

Thanks,
Laxmi NRO, MSFT, SQL Mobile, Microsoft Corporation

|||The easiest way to kick off a Compact on an .sdf file is to use the
"SQLCE Database Viewer" tool.

You don't have to tap on your device's screen once !
It doesn't get much easier than that...

www.pocketpctoolkit.com
Mike
|||WilliBald,

In most cases, SQL CE databases that I have seen become corrupted are on storage cards or other removable storage.

-Darren Shaffer|||Hi Mike,

thanks VERY much!
The tool is great and I've managed to restore the database files!

One more question: Is there a chance to get the mobile binaries also for SH4 processor? - Cause we have devices with that typ of cpu.

regads
willibald|||

hello Mike,

Kindly tell me is there any clue to rectify this ?

Thanks in advance

|||

I have had the same problem with a corrupt SDF file.

All I did was Compact it.

Encrypt it again.

All works fine.

|||As file incourrpt , if the sdf is corrupt , could repair this file is very lucky.

Try to use SqlCeEngine .Repaire method. if failure, reCreate the sdf maybe is the only way .

Friday, March 9, 2012

Recover data from Tables Sql2000

Good Morning,
We have a Win2003 server with SQL2000 running on it. We have an Access Order
Entry application front end with the back end on a database. I was updating
some product pricing in our database and I accidentally DELETED about 360
products. I imported a table with new pricing, and I was updating the prices
in our database with the new prices from an excel spreadsheet.
What is the fastest way I can get back those products? Can I do a roll back
with the trans. log?
Or should I use a backup copy of the database? My automatic maintenance runs
twice a week, so I have backup of the database and logs. But I don't want to
restore the whole database, maybe just one table in the database. Thanks!
Merry Christmas!
Anthony...Although you can't restore a single table, you can restore the entire
database to a different database name and apply your log backups, if needed.
This will allow you to extract the lost data for insertion into your live
database.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Anthony Smith" <anthony@.peconet.com> wrote in message
news:upQJhAP6EHA.2016@.TK2MSFTNGP15.phx.gbl...
> Good Morning,
> We have a Win2003 server with SQL2000 running on it. We have an Access
> Order
> Entry application front end with the back end on a database. I was
> updating
> some product pricing in our database and I accidentally DELETED about 360
> products. I imported a table with new pricing, and I was updating the
> prices
> in our database with the new prices from an excel spreadsheet.
> What is the fastest way I can get back those products? Can I do a roll
> back
> with the trans. log?
> Or should I use a backup copy of the database? My automatic maintenance
> runs
> twice a week, so I have backup of the database and logs. But I don't want
> to
> restore the whole database, maybe just one table in the database. Thanks!
> Merry Christmas!
> Anthony...
>
>|||Thanks for your help. I did it and it work. I'm a SQL novice so I haven't
done much with SQL logs other than back them up.
Have a Merry Christmas!
Anthony...
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:OHjywKP6EHA.2600@.TK2MSFTNGP09.phx.gbl...
> Although you can't restore a single table, you can restore the entire
> database to a different database name and apply your log backups, if
> needed. This will allow you to extract the lost data for insertion into
> your live database.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Anthony Smith" <anthony@.peconet.com> wrote in message
> news:upQJhAP6EHA.2016@.TK2MSFTNGP15.phx.gbl...
>> Good Morning,
>> We have a Win2003 server with SQL2000 running on it. We have an Access
>> Order
>> Entry application front end with the back end on a database. I was
>> updating
>> some product pricing in our database and I accidentally DELETED about 360
>> products. I imported a table with new pricing, and I was updating the
>> prices
>> in our database with the new prices from an excel spreadsheet.
>> What is the fastest way I can get back those products? Can I do a roll
>> back
>> with the trans. log?
>> Or should I use a backup copy of the database? My automatic maintenance
>> runs
>> twice a week, so I have backup of the database and logs. But I don't want
>> to
>> restore the whole database, maybe just one table in the database.
>> Thanks!
>> Merry Christmas!
>> Anthony...
>>
>|||That's better than most novices; at least you know they exist and have the
sense to back them up.
Sincerely,
Anthony Thomas
"Anthony Smith" <anthony@.peconet.com> wrote in message
news:eMsKduP6EHA.1596@.tk2msftngp13.phx.gbl...
Thanks for your help. I did it and it work. I'm a SQL novice so I haven't
done much with SQL logs other than back them up.
Have a Merry Christmas!
Anthony...
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:OHjywKP6EHA.2600@.TK2MSFTNGP09.phx.gbl...
> Although you can't restore a single table, you can restore the entire
> database to a different database name and apply your log backups, if
> needed. This will allow you to extract the lost data for insertion into
> your live database.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Anthony Smith" <anthony@.peconet.com> wrote in message
> news:upQJhAP6EHA.2016@.TK2MSFTNGP15.phx.gbl...
>> Good Morning,
>> We have a Win2003 server with SQL2000 running on it. We have an Access
>> Order
>> Entry application front end with the back end on a database. I was
>> updating
>> some product pricing in our database and I accidentally DELETED about 360
>> products. I imported a table with new pricing, and I was updating the
>> prices
>> in our database with the new prices from an excel spreadsheet.
>> What is the fastest way I can get back those products? Can I do a roll
>> back
>> with the trans. log?
>> Or should I use a backup copy of the database? My automatic maintenance
>> runs
>> twice a week, so I have backup of the database and logs. But I don't want
>> to
>> restore the whole database, maybe just one table in the database.
>> Thanks!
>> Merry Christmas!
>> Anthony...
>>
>

Wednesday, March 7, 2012

Recordset opens as read-only -- WHY?

Hello,
I have a C++ / MFC app which uses CDatabase and CRecordset to connect to a
ODBC data source for a SQL Server 7 database. The application worked
properly with a MySQL database, but after swapping it for SQL Server
problems emerged. In particular, any calls to CRecordset::AddNew() and
CRecordset::Edit() cause an exception to be thrown with the error message
"Recordset is read-only". Stepping through the code for CRecordset::Open(),
I can see that it indeeds fail to open the recordset with SQL_CONCUR_ROWVER
and SQL_CONCUR_LOCK, finally succeeding with SQL_CONCUR_READ_ONLY. I need to
be able to write to the db!! What is going on here?
I call CRecordset::Open() with no SQL string and no options (which defaults
to full access and not read-only).
I am not a SQL Server expert, but I tried playing with the config a little
bit:
- The database is NOT set for read-only.
- The database option "Restrict Access" is NOT selected.
- I checkmarked all permissions (SELECT, INSERT, UPDATE, DELETE, DRI)
for my app's user on all tables in the db.
- My connection string uses the user 'sa', which is the login name for
the user 'dbo'.
In the ODBC data source config, I set authentication to SQL Server
authentication, and accepted the default for all the other options.
I haven't tried using a different class (say, CDaoRecordset) nor do I plan
on doing that. I really need to get this to work with CRecordset. Any help
is appreciated.
Thanks,
SL
"Silvio Lopes de Oliveira" <silviol@.aaesys.com> wrote in message
news:s91wc.11$5Z4.18584@.news.uswest.net...
> Hello,
> I have a C++ / MFC app which uses CDatabase and CRecordset to connect to a
> ODBC data source for a SQL Server 7 database. The application worked
> properly with a MySQL database, but after swapping it for SQL Server
> problems emerged. In particular, any calls to CRecordset::AddNew() and
> CRecordset::Edit() cause an exception to be thrown with the error message
> "Recordset is read-only". Stepping through the code for
CRecordset::Open(),
> I can see that it indeeds fail to open the recordset with
SQL_CONCUR_ROWVER
> and SQL_CONCUR_LOCK, finally succeeding with SQL_CONCUR_READ_ONLY. I need
to
> be able to write to the db!! What is going on here?
> I call CRecordset::Open() with no SQL string and no options (which
defaults
> to full access and not read-only).
> I am not a SQL Server expert, but I tried playing with the config a little
> bit:
> - The database is NOT set for read-only.
> - The database option "Restrict Access" is NOT selected.
> - I checkmarked all permissions (SELECT, INSERT, UPDATE, DELETE, DRI)
> for my app's user on all tables in the db.
> - My connection string uses the user 'sa', which is the login name for
> the user 'dbo'.
> In the ODBC data source config, I set authentication to SQL Server
> authentication, and accepted the default for all the other options.
> I haven't tried using a different class (say, CDaoRecordset) nor do I plan
> on doing that. I really need to get this to work with CRecordset. Any help
> is appreciated.
> Thanks,
> SL
>
This is a guess, but does the table you're working with have a primary key?
Many client tools will not update a table unless there is a primary key
present, as without a key there is no way to identify the rows you want to
update. Or if your recordset is returned by a stored procedure you might be
seeing an issue like this:
http://support.microsoft.com/default...b;en-us;246636
However, I don't do much client-side coding, so I might be on completely the
wrong track here.
Simon
|||Silvio Lopes de Oliveira (silviol@.aaesys.com) writes:
> I have a C++ / MFC app which uses CDatabase and CRecordset to connect to
> a ODBC data source for a SQL Server 7 database. The application worked
> properly with a MySQL database, but after swapping it for SQL Server
> problems emerged. In particular, any calls to CRecordset::AddNew() and
> CRecordset::Edit() cause an exception to be thrown with the error
> message "Recordset is read-only". Stepping through the code for
> CRecordset::Open(), I can see that it indeeds fail to open the recordset
> with SQL_CONCUR_ROWVER and SQL_CONCUR_LOCK, finally succeeding with
> SQL_CONCUR_READ_ONLY. I need to be able to write to the db!! What is
> going on here?
It would have helped if you had posted the query.
I would guess that the reason is that the query is such that SQL
Server will not be able to determine which row to update. This
could be because, as Simon pointed out, of a missing primary key.
But it can also happen if you use GROUP BY, expressions or a whole
load number of things.
When this happens to people in their stored procedures, I recommend
them to not use WHERE CURRENT OF, but use a regular WHERE clause
instead. In your case, this would mean that you would submit a
regular UPDATE statement. But I guess that would be through a
different connection, because the one where you have the cursor
may be busy. And depending on which locking scheme you have on your
cursor, you may look yourself.
The remedy for this would be to get all data into the client, and
the close the cursor, and then you can update from the regular
connection. Unless the amount of data is huge, this is likely to
be more effecient. (And if the amount of data is huge, then using a
stored procedure with all the update logic and never get the data
to he client, would be a big winner.)
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp
|||As a matter of fact, it was the lack of a primary key field that caused the
problem. When I imported the tables and data from my MySQL database, the
primary key fields were not marked as such in the SQL Server tables.
Problem fixed. Thanks!
Silvio
"Simon Hayes" <sql@.hayes.ch> wrote in message
news:40c0aeb6$1_3@.news.bluewin.ch...[vbcol=seagreen]
> "Silvio Lopes de Oliveira" <silviol@.aaesys.com> wrote in message
> news:s91wc.11$5Z4.18584@.news.uswest.net...
a[vbcol=seagreen]
message[vbcol=seagreen]
> CRecordset::Open(),
> SQL_CONCUR_ROWVER
need[vbcol=seagreen]
> to
> defaults
little[vbcol=seagreen]
DRI)[vbcol=seagreen]
for[vbcol=seagreen]
plan[vbcol=seagreen]
help
> This is a guess, but does the table you're working with have a primary
key?
> Many client tools will not update a table unless there is a primary key
> present, as without a key there is no way to identify the rows you want to
> update. Or if your recordset is returned by a stored procedure you might
be
> seeing an issue like this:
> http://support.microsoft.com/default...b;en-us;246636
> However, I don't do much client-side coding, so I might be on completely
the
> wrong track here.
> Simon
>

Recordset opens as read-only -- WHY?

Hello,

I have a C++ / MFC app which uses CDatabase and CRecordset to connect to a
ODBC data source for a SQL Server 7 database. The application worked
properly with a MySQL database, but after swapping it for SQL Server
problems emerged. In particular, any calls to CRecordset::AddNew() and
CRecordset::Edit() cause an exception to be thrown with the error message
"Recordset is read-only". Stepping through the code for CRecordset::Open(),
I can see that it indeeds fail to open the recordset with SQL_CONCUR_ROWVER
and SQL_CONCUR_LOCK, finally succeeding with SQL_CONCUR_READ_ONLY. I need to
be able to write to the db!! What is going on here??

I call CRecordset::Open() with no SQL string and no options (which defaults
to full access and not read-only).

I am not a SQL Server expert, but I tried playing with the config a little
bit:
- The database is NOT set for read-only.
- The database option "Restrict Access" is NOT selected.
- I checkmarked all permissions (SELECT, INSERT, UPDATE, DELETE, DRI)
for my app's user on all tables in the db.
- My connection string uses the user 'sa', which is the login name for
the user 'dbo'.

In the ODBC data source config, I set authentication to SQL Server
authentication, and accepted the default for all the other options.

I haven't tried using a different class (say, CDaoRecordset) nor do I plan
on doing that. I really need to get this to work with CRecordset. Any help
is appreciated.

Thanks,

SL"Silvio Lopes de Oliveira" <silviol@.aaesys.com> wrote in message
news:s91wc.11$5Z4.18584@.news.uswest.net...
> Hello,
> I have a C++ / MFC app which uses CDatabase and CRecordset to connect to a
> ODBC data source for a SQL Server 7 database. The application worked
> properly with a MySQL database, but after swapping it for SQL Server
> problems emerged. In particular, any calls to CRecordset::AddNew() and
> CRecordset::Edit() cause an exception to be thrown with the error message
> "Recordset is read-only". Stepping through the code for
CRecordset::Open(),
> I can see that it indeeds fail to open the recordset with
SQL_CONCUR_ROWVER
> and SQL_CONCUR_LOCK, finally succeeding with SQL_CONCUR_READ_ONLY. I need
to
> be able to write to the db!! What is going on here??
> I call CRecordset::Open() with no SQL string and no options (which
defaults
> to full access and not read-only).
> I am not a SQL Server expert, but I tried playing with the config a little
> bit:
> - The database is NOT set for read-only.
> - The database option "Restrict Access" is NOT selected.
> - I checkmarked all permissions (SELECT, INSERT, UPDATE, DELETE, DRI)
> for my app's user on all tables in the db.
> - My connection string uses the user 'sa', which is the login name for
> the user 'dbo'.
> In the ODBC data source config, I set authentication to SQL Server
> authentication, and accepted the default for all the other options.
> I haven't tried using a different class (say, CDaoRecordset) nor do I plan
> on doing that. I really need to get this to work with CRecordset. Any help
> is appreciated.
> Thanks,
> SL

This is a guess, but does the table you're working with have a primary key?
Many client tools will not update a table unless there is a primary key
present, as without a key there is no way to identify the rows you want to
update. Or if your recordset is returned by a stored procedure you might be
seeing an issue like this:

http://support.microsoft.com/defaul...kb;en-us;246636

However, I don't do much client-side coding, so I might be on completely the
wrong track here.

Simon|||Silvio Lopes de Oliveira (silviol@.aaesys.com) writes:
> I have a C++ / MFC app which uses CDatabase and CRecordset to connect to
> a ODBC data source for a SQL Server 7 database. The application worked
> properly with a MySQL database, but after swapping it for SQL Server
> problems emerged. In particular, any calls to CRecordset::AddNew() and
> CRecordset::Edit() cause an exception to be thrown with the error
> message "Recordset is read-only". Stepping through the code for
> CRecordset::Open(), I can see that it indeeds fail to open the recordset
> with SQL_CONCUR_ROWVER and SQL_CONCUR_LOCK, finally succeeding with
> SQL_CONCUR_READ_ONLY. I need to be able to write to the db!! What is
> going on here??

It would have helped if you had posted the query.

I would guess that the reason is that the query is such that SQL
Server will not be able to determine which row to update. This
could be because, as Simon pointed out, of a missing primary key.
But it can also happen if you use GROUP BY, expressions or a whole
load number of things.

When this happens to people in their stored procedures, I recommend
them to not use WHERE CURRENT OF, but use a regular WHERE clause
instead. In your case, this would mean that you would submit a
regular UPDATE statement. But I guess that would be through a
different connection, because the one where you have the cursor
may be busy. And depending on which locking scheme you have on your
cursor, you may look yourself.

The remedy for this would be to get all data into the client, and
the close the cursor, and then you can update from the regular
connection. Unless the amount of data is huge, this is likely to
be more effecient. (And if the amount of data is huge, then using a
stored procedure with all the update logic and never get the data
to he client, would be a big winner.)

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||As a matter of fact, it was the lack of a primary key field that caused the
problem. When I imported the tables and data from my MySQL database, the
primary key fields were not marked as such in the SQL Server tables.

Problem fixed. Thanks!

Silvio

"Simon Hayes" <sql@.hayes.ch> wrote in message
news:40c0aeb6$1_3@.news.bluewin.ch...
> "Silvio Lopes de Oliveira" <silviol@.aaesys.com> wrote in message
> news:s91wc.11$5Z4.18584@.news.uswest.net...
> > Hello,
> > I have a C++ / MFC app which uses CDatabase and CRecordset to connect to
a
> > ODBC data source for a SQL Server 7 database. The application worked
> > properly with a MySQL database, but after swapping it for SQL Server
> > problems emerged. In particular, any calls to CRecordset::AddNew() and
> > CRecordset::Edit() cause an exception to be thrown with the error
message
> > "Recordset is read-only". Stepping through the code for
> CRecordset::Open(),
> > I can see that it indeeds fail to open the recordset with
> SQL_CONCUR_ROWVER
> > and SQL_CONCUR_LOCK, finally succeeding with SQL_CONCUR_READ_ONLY. I
need
> to
> > be able to write to the db!! What is going on here??
> > I call CRecordset::Open() with no SQL string and no options (which
> defaults
> > to full access and not read-only).
> > I am not a SQL Server expert, but I tried playing with the config a
little
> > bit:
> > - The database is NOT set for read-only.
> > - The database option "Restrict Access" is NOT selected.
> > - I checkmarked all permissions (SELECT, INSERT, UPDATE, DELETE,
DRI)
> > for my app's user on all tables in the db.
> > - My connection string uses the user 'sa', which is the login name
for
> > the user 'dbo'.
> > In the ODBC data source config, I set authentication to SQL Server
> > authentication, and accepted the default for all the other options.
> > I haven't tried using a different class (say, CDaoRecordset) nor do I
plan
> > on doing that. I really need to get this to work with CRecordset. Any
help
> > is appreciated.
> > Thanks,
> > SL
> This is a guess, but does the table you're working with have a primary
key?
> Many client tools will not update a table unless there is a primary key
> present, as without a key there is no way to identify the rows you want to
> update. Or if your recordset is returned by a stored procedure you might
be
> seeing an issue like this:
> http://support.microsoft.com/defaul...kb;en-us;246636
> However, I don't do much client-side coding, so I might be on completely
the
> wrong track here.
> Simon

Friday, March 30, 2012

Recovery of database 'abcdef'...

Recovery of database 'abcdef'...

Recovery of database 'abcdef'...

Recovery of database

Recovery of database

Recovery of database

Friday, March 23, 2012

Recovering from Deadlocks: retrying the query

Tuesday, March 20, 2012

Recover SDF-File

Recover SDF-File

Recover SDF-File

Recover SDF-File

Recover SDF-File

Recover SDF-File

Friday, March 9, 2012

Recover data from Tables Sql2000

Recover data from Tables Sql2000

Wednesday, March 7, 2012

Recordset opens as read-only -- WHY?

Recordset opens as read-only -- WHY?

Record Locks

Blog Archive

About Me