Showing posts with label old. Show all posts
Showing posts with label old. Show all posts

Thursday, March 8, 2012

"Remove files older than" does not work

Hi.
The Database Maintenance Plan that is configured to backup
the DB every day as the "Remove files older than" option
set to 1 days.
The old files are no being removed. The backups are
working and placed in the specified folder. The "Backup
file extension:" is "bak". What am I missing?
Thanx.Does
BUG: Sqlmaint Does Not Delete Expired Backup Files on Windows 95, 98 or ME
Computers
http://support.microsoft.com/default.aspx?scid=kb;en-us;278667
apply?
--
Jacco Schalkwijk
SQL Server MVP
"Hector" <anonymous@.discussions.microsoft.com> wrote in message
news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
> Hi.
> The Database Maintenance Plan that is configured to backup
> the DB every day as the "Remove files older than" option
> set to 1 days.
> The old files are no being removed. The backups are
> working and placed in the specified folder. The "Backup
> file extension:" is "bak". What am I missing?
> Thanx.|||The server runs Windows 2000 (SP4).
I might be missing part of your response. It's sort of
distored.
Thanx!
>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message
>news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
>> Hi.
>> The Database Maintenance Plan that is configured to
backup
>> the DB every day as the "Remove files older than" option
>> set to 1 days.
>> The old files are no being removed. The backups are
>> working and placed in the specified folder. The "Backup
>> file extension:" is "bak". What am I missing?
>> Thanx.
>
>.
>|||I'm sorry. Now I understood your message. I'm reading
the article now.
Thanx again.
>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message
>news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
>> Hi.
>> The Database Maintenance Plan that is configured to
backup
>> the DB every day as the "Remove files older than" option
>> set to 1 days.
>> The old files are no being removed. The backups are
>> working and placed in the specified folder. The "Backup
>> file extension:" is "bak". What am I missing?
>> Thanx.
>
>.
>|||I reviewed the article and it doesn't apply. We have SQL
Server 2000 running on a Windows 2000 Server.
>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message
>news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
>> Hi.
>> The Database Maintenance Plan that is configured to
backup
>> the DB every day as the "Remove files older than" option
>> set to 1 days.
>> The old files are no being removed. The backups are
>> working and placed in the specified folder. The "Backup
>> file extension:" is "bak". What am I missing?
>> Thanx.
>
>.
>|||Below KB might help:
http://support.microsoft.com/default.aspx?scid=kb;en-us;303292&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Hector" <anonymous@.discussions.microsoft.com> wrote in message
news:217f301c45ac5$cfffc700$a501280a@.phx.gbl...
> I reviewed the article and it doesn't apply. We have SQL
> Server 2000 running on a Windows 2000 Server.
>
> >--Original Message--
> >Does
> >BUG: Sqlmaint Does Not Delete Expired Backup Files on
> Windows 95, 98 or ME
> >Computers
> >http://support.microsoft.com/default.aspx?scid=kb;en-
> us;278667
> >apply?
> >
> >--
> >Jacco Schalkwijk
> >SQL Server MVP
> >
> >
> >"Hector" <anonymous@.discussions.microsoft.com> wrote in
> message
> >news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
> >> Hi.
> >>
> >> The Database Maintenance Plan that is configured to
> backup
> >> the DB every day as the "Remove files older than" option
> >> set to 1 days.
> >>
> >> The old files are no being removed. The backups are
> >> working and placed in the specified folder. The "Backup
> >> file extension:" is "bak". What am I missing?
> >>
> >> Thanx.
> >
> >
> >.
> >|||I've recently taken over management of an SQL 2000 server also o
Windows 2000 server (and relatively new to SQL) and have exactly th
same problem.
Read through this thread but as yet no success to resolving th
problem.
Hector - did you get this resolved?
Anyone have any other ideas not suggested here?
Regards,
Glen.
Did you ever get a fix?
Hector wrote:
> *Hi.
> The Database Maintenance Plan that is configured to backup
> the DB every day as the "Remove files older than" option
> set to 1 days.
> The old files are no being removed. The backups are
> working and placed in the specified folder. The "Backup
> file extension:" is "bak". What am I missing?
> Thanx.
-
Glen Sutti
----
Posted via http://www.webservertalk.co
----
View this thread: http://www.webservertalk.com/message273097.htm|||I don't have access to the old thread, but perhaps below might help?
Below KB might help:
http://support.microsoft.com/default.aspx?scid=kb;en-us;303292&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Glen Suttie" <Glen.Suttie.1hdx2u@.mail.webservertalk.com> wrote in message
news:Glen.Suttie.1hdx2u@.mail.webservertalk.com...
> I've recently taken over management of an SQL 2000 server also on
> Windows 2000 server (and relatively new to SQL) and have exactly the
> same problem.
> Read through this thread but as yet no success to resolving the
> problem.
> Hector - did you get this resolved?
> Anyone have any other ideas not suggested here?
> Regards,
> Glen.
>
>
> Did you ever get a fix?
> Hector wrote:
>> *Hi.
>> The Database Maintenance Plan that is configured to backup
>> the DB every day as the "Remove files older than" option
>> set to 1 days.
>> The old files are no being removed. The backups are
>> working and placed in the specified folder. The "Backup
>> file extension:" is "bak". What am I missing?
>> Thanx. *
>
> --
> Glen Suttie
> ---
> Posted via http://www.webservertalk.com
> ---
> View this thread: http://www.webservertalk.com/message273097.html
>

"Remove files older than" does not work

Hi.
The Database Maintenance Plan that is configured to backup
the DB every day as the "Remove files older than" option
set to 1 days.
The old files are no being removed. The backups are
working and placed in the specified folder. The "Backup
file extension:" is "bak". What am I missing?
Thanx.
Does
BUG: Sqlmaint Does Not Delete Expired Backup Files on Windows 95, 98 or ME
Computers
http://support.microsoft.com/default...b;en-us;278667
apply?
Jacco Schalkwijk
SQL Server MVP
"Hector" <anonymous@.discussions.microsoft.com> wrote in message
news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
> Hi.
> The Database Maintenance Plan that is configured to backup
> the DB every day as the "Remove files older than" option
> set to 1 days.
> The old files are no being removed. The backups are
> working and placed in the specified folder. The "Backup
> file extension:" is "bak". What am I missing?
> Thanx.
|||The server runs Windows 2000 (SP4).
I might be missing part of your response. It's sort of
distored.
Thanx!

>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
backup
>
>.
>
|||I'm sorry. Now I understood your message. I'm reading
the article now.
Thanx again.

>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
backup
>
>.
>
|||I reviewed the article and it doesn't apply. We have SQL
Server 2000 running on a Windows 2000 Server.

>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:2176001c45ab8$54616d90$a401280a@.phx.gbl...
backup
>
>.
>
|||Below KB might help:
http://support.microsoft.com/default...&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Hector" <anonymous@.discussions.microsoft.com> wrote in message
news:217f301c45ac5$cfffc700$a501280a@.phx.gbl...[vbcol=seagreen]
> I reviewed the article and it doesn't apply. We have SQL
> Server 2000 running on a Windows 2000 Server.
>
> Windows 95, 98 or ME
> us;278667
> message
> backup
|||I've recently taken over management of an SQL 2000 server also on
Windows 2000 server (and relatively new to SQL) and have exactly the
same problem.
Read through this thread but as yet no success to resolving the
problem.
Hector - did you get this resolved?
Anyone have any other ideas not suggested here?
Regards,
Glen.
Did you ever get a fix?
Hector wrote:
> *Hi.
> The Database Maintenance Plan that is configured to backup
> the DB every day as the "Remove files older than" option
> set to 1 days.
> The old files are no being removed. The backups are
> working and placed in the specified folder. The "Backup
> file extension:" is "bak". What am I missing?
> Thanx. *
Glen Suttie
Posted via http://www.webservertalk.com
View this thread: http://www.webservertalk.com/message273097.html
|||I don't have access to the old thread, but perhaps below might help?
Below KB might help:
http://support.microsoft.com/default...&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Glen Suttie" <Glen.Suttie.1hdx2u@.mail.webservertalk.com> wrote in message
news:Glen.Suttie.1hdx2u@.mail.webservertalk.com...
> I've recently taken over management of an SQL 2000 server also on
> Windows 2000 server (and relatively new to SQL) and have exactly the
> same problem.
> Read through this thread but as yet no success to resolving the
> problem.
> Hector - did you get this resolved?
> Anyone have any other ideas not suggested here?
> Regards,
> Glen.
>
>
> Did you ever get a fix?
> Hector wrote:
>
> --
> Glen Suttie
> Posted via http://www.webservertalk.com
> View this thread: http://www.webservertalk.com/message273097.html
>

"Remove files older than" does not work

Hi.
The Database Maintenance Plan that is configured to backup
the DB every day as the "Remove files older than" option
set to 1 days.
The old files are no being removed. The backups are
working and placed in the specified folder. The "Backup
file extension:" is "bak". What am I missing?
Thanx.Does
BUG: Sqlmaint Does Not Delete Expired Backup Files on Windows 95, 98 or ME
Computers
http://support.microsoft.com/defaul...kb;en-us;278667
apply?
Jacco Schalkwijk
SQL Server MVP
"Hector" <anonymous@.discussions.microsoft.com> wrote in message
news:2176001c45ab8$54616d90$a401280a@.phx
.gbl...
> Hi.
> The Database Maintenance Plan that is configured to backup
> the DB every day as the "Remove files older than" option
> set to 1 days.
> The old files are no being removed. The backups are
> working and placed in the specified folder. The "Backup
> file extension:" is "bak". What am I missing?
> Thanx.|||The server runs Windows 2000 (SP4).
I might be missing part of your response. It's sort of
distored.
Thanx!

>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message
> news:2176001c45ab8$54616d90$a401280a@.phx
.gbl...
backup[vbcol=seagreen]
>
>.
>|||I'm sorry. Now I understood your message. I'm reading
the article now.
Thanx again.

>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message
> news:2176001c45ab8$54616d90$a401280a@.phx
.gbl...
backup[vbcol=seagreen]
>
>.
>|||I reviewed the article and it doesn't apply. We have SQL
Server 2000 running on a Windows 2000 Server.

>--Original Message--
>Does
>BUG: Sqlmaint Does Not Delete Expired Backup Files on
Windows 95, 98 or ME
>Computers
>http://support.microsoft.com/default.aspx?scid=kb;en-
us;278667
>apply?
>--
>Jacco Schalkwijk
>SQL Server MVP
>
>"Hector" <anonymous@.discussions.microsoft.com> wrote in
message
> news:2176001c45ab8$54616d90$a401280a@.phx
.gbl...
backup[vbcol=seagreen]
>
>.
>|||Below KB might help:
http://support.microsoft.com/defaul...2&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Hector" <anonymous@.discussions.microsoft.com> wrote in message
news:217f301c45ac5$cfffc700$a501280a@.phx
.gbl...[vbcol=seagreen]
> I reviewed the article and it doesn't apply. We have SQL
> Server 2000 running on a Windows 2000 Server.
>
> Windows 95, 98 or ME
> us;278667
> message
> backup|||I've recently taken over management of an SQL 2000 server also on Windows 20
00 server (and relatively new to SQL) and have exactly the same problem.
Read through this thread but as yet no success to resolving the problem.
Hector - did you get this resolved?
Anyone have any other ideas not suggested here?
Regards,
Glen.
Did you ever get a fix?
quote:
Originally posted by Hector
Hi.
The Database Maintenance Plan that is configured to backup
the DB every day as the "Remove files older than" option
set to 1 days.
The old files are no being removed. The backups are
working and placed in the specified folder. The "Backup
file extension:" is "bak". What am I missing?
Thanx.

|||I don't have access to the old thread, but perhaps below might help?
Below KB might help:
http://support.microsoft.com/defaul...2&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Glen Suttie" <Glen.Suttie.1hdx2u@.mail.webservertalk.com> wrote in message
news:Glen.Suttie.1hdx2u@.mail.webservertalk.com...
> I've recently taken over management of an SQL 2000 server also on
> Windows 2000 server (and relatively new to SQL) and have exactly the
> same problem.
> Read through this thread but as yet no success to resolving the
> problem.
> Hector - did you get this resolved?
> Anyone have any other ideas not suggested here?
> Regards,
> Glen.
>
>
> Did you ever get a fix?
> Hector wrote:
>
> --
> Glen Suttie
> ---
> Posted via http://www.webservertalk.com
> ---
> View this thread: http://www.webservertalk.com/message273097.html
>

Friday, January 27, 2012

Comment disables code?

It seem that using the old "--" style comment screws code in the IDE under
certain circumstances. As an example, the code in example one should create
a temporary table, populate it with the current int ID from a table along
with an int IDENTITY column that will serve as the new ID, then display the
resulting temporary table. The code runs as expected without the -- Comment
line, but as soon as it is added the table no longer populates, and the
temporary table is no longer displayed. The same type thing seems to happen
when you place -- comments following values in a SELECT statement as in
example two.
I ran the code under both Query Analyzer and the new 2005 IDE and they both
exhibited thje same behavior, but I've used the -- comment style for years
without an issue so I'm baffled. So far it only seems to affect SELECT
statements.
Has anyone else encountered this?
/* Example One */
PRINT '*** Create the LotEntity ID mapping table';
IF EXISTS(SELECT * FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME =
'LotEntity')
DROP TABLE tempdb.dbo.LotEntity
CREATE TABLE tempdb.dbo.LotEntity(OldID int, NewID int IDENTITY)
-- Comment
INSERT tempdb.dbo.LotEntity (OldID)
SELECT EntityID
FROM dbo.tbl_LotEntities
SELECT * FROM tempdb.dbo.LotEntity
/* Example 2 */
INSERT TableTwo (
ColumnOne,
ColumnTwo)
SELECT
ValueOne, -- ColumnOne
ValueTwo
FROM TableTwoI couldn't reproduce either of those problems.
For example 1, the problem probably not the comment, but that you do the SEL
ECT in the INSERT in the
same batch as the table is created. My guess is that the parses gets confuse
d when you in the same
batch creates a table, and then does a SELECT inside an INSERT where both of
these later statements
refer to the same table. That code generated an error (probably from the SEL
ECT inside the INSERT)
regardless of whether I have the comment or not.
For example 1, I got a proper error message stating that the table doesn't e
xist. And if I create
the table, no errors:
DROP TABLE TableTwo
GO
CREATE TABLE TableTwo (ColumnOne int, ColumnTwo int, ValueOne int, ValueTwo
int)
GO
INSERT TableTwo (
ColumnOne,
ColumnTwo)
SELECT
ValueOne, -- ColumnOne
ValueTwo
FROM TableTwo
If you can post a full repro, we can have a look at it. Oh, watch out for ed
itors etc that doesn't
produce a full CRLF. I've seen cases when you have only a CR (or was it LF)
which visually produces
a new line, but doesn't end the comment.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Byron" <Byron@.discussions.microsoft.com> wrote in message
news:BF89D3A3-A798-4220-852F-7A5FCC33971E@.microsoft.com...
> It seem that using the old "--" style comment screws code in the IDE under
> certain circumstances. As an example, the code in example one should crea
te
> a temporary table, populate it with the current int ID from a table along
> with an int IDENTITY column that will serve as the new ID, then display th
e
> resulting temporary table. The code runs as expected without the -- Comme
nt
> line, but as soon as it is added the table no longer populates, and the
> temporary table is no longer displayed. The same type thing seems to happ
en
> when you place -- comments following values in a SELECT statement as in
> example two.
> I ran the code under both Query Analyzer and the new 2005 IDE and they bot
h
> exhibited thje same behavior, but I've used the -- comment style for years
> without an issue so I'm baffled. So far it only seems to affect SELECT
> statements.
> Has anyone else encountered this?
>
> /* Example One */
> PRINT '*** Create the LotEntity ID mapping table';
> IF EXISTS(SELECT * FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME
=
> 'LotEntity')
> DROP TABLE tempdb.dbo.LotEntity
> CREATE TABLE tempdb.dbo.LotEntity(OldID int, NewID int IDENTITY)
> -- Comment
> INSERT tempdb.dbo.LotEntity (OldID)
> SELECT EntityID
> FROM dbo.tbl_LotEntities
> SELECT * FROM tempdb.dbo.LotEntity
>
> /* Example 2 */
> INSERT TableTwo (
> ColumnOne,
> ColumnTwo)
> SELECT
> ValueOne, -- ColumnOne
> ValueTwo
> FROM TableTwo
>|||The example code stands alone, using a table valued variable in place of my
real table, but the results are the same. When Example 1 is run it correctl
y
retuns the two rows are expected. When Example 2 is run it does not.
Now the freaky part I just discovered while doing these examples. I can
copy the problematic code block including the comment out of my main query
into a new query window and it fails. I then copy it into Notepad then back
out into a query window and it works.
Some of the code was created using a stored procedure that built the SQL
strings based on table structures and I used CHAR(13) for CRLF to format the
code. Is it possible that the absence of CHAR(10) is confusing SQL? The
code was edited and saved in SQL Server Management Studio after it was
generated and the piece of code that is failing was not generated; it was
created by hand, but was added the file that had generated code in it .
/* Example 1 */
SET NOCOUNT ON
DECLARE @.t TABLE(ID int)
INSERT @.t VALUES(1)
INSERT @.t VALUES(2)
PRINT '*** Create the LotEntity ID mapping table';
IF EXISTS(SELECT * FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME =
'LotEntity')
DROP TABLE tempdb.dbo.LotEntity
CREATE TABLE tempdb.dbo.LotEntity(OldID int, NewID int IDENTITY)
INSERT tempdb.dbo.LotEntity (OldID)
SELECT ID
FROM @.t
SELECT * FROM tempdb.dbo.LotEntity
/* Example 1 results */
*** Create the LotEntity ID mapping table
OldID NewID
-- --
1 1
2 2
/* Example 2 */
SET NOCOUNT ON
DECLARE @.t TABLE(ID int)
INSERT @.t VALUES(1)
INSERT @.t VALUES(2)
PRINT '*** Create the LotEntity ID mapping table';
IF EXISTS(SELECT * FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME =
'LotEntity')
DROP TABLE tempdb.dbo.LotEntity
CREATE TABLE tempdb.dbo.LotEntity(OldID int, NewID int IDENTITY)
-- Comment
INSERT tempdb.dbo.LotEntity (OldID)
SELECT ID
FROM @.t
SELECT * FROM tempdb.dbo.LotEntity
/* Example 2 results */
*** Create the LotEntity ID mapping table
"Byron" wrote:

> It seem that using the old "--" style comment screws code in the IDE under
> certain circumstances. As an example, the code in example one should crea
te
> a temporary table, populate it with the current int ID from a table along
> with an int IDENTITY column that will serve as the new ID, then display th
e
> resulting temporary table. The code runs as expected without the -- Comme
nt
> line, but as soon as it is added the table no longer populates, and the
> temporary table is no longer displayed. The same type thing seems to happ
en
> when you place -- comments following values in a SELECT statement as in
> example two.
> I ran the code under both Query Analyzer and the new 2005 IDE and they bot
h
> exhibited thje same behavior, but I've used the -- comment style for years
> without an issue so I'm baffled. So far it only seems to affect SELECT
> statements.
> Has anyone else encountered this?
>
> /* Example One */
> PRINT '*** Create the LotEntity ID mapping table';
> IF EXISTS(SELECT * FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME
=
> 'LotEntity')
> DROP TABLE tempdb.dbo.LotEntity
> CREATE TABLE tempdb.dbo.LotEntity(OldID int, NewID int IDENTITY)
> -- Comment
> INSERT tempdb.dbo.LotEntity (OldID)
> SELECT EntityID
> FROM dbo.tbl_LotEntities
> SELECT * FROM tempdb.dbo.LotEntity
>
> /* Example 2 */
> INSERT TableTwo (
> ColumnOne,
> ColumnTwo)
> SELECT
> ValueOne, -- ColumnOne
> ValueTwo
> FROM TableTwo
>|||> Some of the code was created using a stored procedure that built the SQL
> strings based on table structures and I used CHAR(13) for CRLF to format t
he
> code. Is it possible that the absence of CHAR(10) is confusing SQL?
Most probably. Make sure you have CHAR(13) + CHAR(10) and you should be fine
.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Byron" <Byron@.discussions.microsoft.com> wrote in message
news:ACFB2214-1B3A-4794-B5ED-FE8B55D0B167@.microsoft.com...
> The example code stands alone, using a table valued variable in place of m
y
> real table, but the results are the same. When Example 1 is run it correc
tly
> retuns the two rows are expected. When Example 2 is run it does not.
> Now the freaky part I just discovered while doing these examples. I can
> copy the problematic code block including the comment out of my main query
> into a new query window and it fails. I then copy it into Notepad then ba
ck
> out into a query window and it works.
> Some of the code was created using a stored procedure that built the SQL
> strings based on table structures and I used CHAR(13) for CRLF to format t
he
> code. Is it possible that the absence of CHAR(10) is confusing SQL? The
> code was edited and saved in SQL Server Management Studio after it was
> generated and the piece of code that is failing was not generated; it was
> created by hand, but was added the file that had generated code in it .
> /* Example 1 */
> SET NOCOUNT ON
> DECLARE @.t TABLE(ID int)
> INSERT @.t VALUES(1)
> INSERT @.t VALUES(2)
> PRINT '*** Create the LotEntity ID mapping table';
> IF EXISTS(SELECT * FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME
=
> 'LotEntity')
> DROP TABLE tempdb.dbo.LotEntity
> CREATE TABLE tempdb.dbo.LotEntity(OldID int, NewID int IDENTITY)
> INSERT tempdb.dbo.LotEntity (OldID)
> SELECT ID
> FROM @.t
> SELECT * FROM tempdb.dbo.LotEntity
> /* Example 1 results */
> *** Create the LotEntity ID mapping table
> OldID NewID
> -- --
> 1 1
> 2 2
>
> /* Example 2 */
> SET NOCOUNT ON
> DECLARE @.t TABLE(ID int)
> INSERT @.t VALUES(1)
> INSERT @.t VALUES(2)
> PRINT '*** Create the LotEntity ID mapping table';
> IF EXISTS(SELECT * FROM tempdb.INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME
=
> 'LotEntity')
> DROP TABLE tempdb.dbo.LotEntity
> CREATE TABLE tempdb.dbo.LotEntity(OldID int, NewID int IDENTITY)
> -- Comment
> INSERT tempdb.dbo.LotEntity (OldID)
> SELECT ID
> FROM @.t
> SELECT * FROM tempdb.dbo.LotEntity
> /* Example 2 results */
> *** Create the LotEntity ID mapping table
>
> "Byron" wrote:
>|||Probably a good Idea to store the CHAR(13) + CHAR(10) in a variable so you
are not having to do that many calls for every line of dynamic code you
create. Yes its subsecond but if you throw millions of records at the
procedure you could run into some issues with performance.
"Tibor Karaszi" wrote:

> Most probably. Make sure you have CHAR(13) + CHAR(10) and you should be fi
ne.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Byron" <Byron@.discussions.microsoft.com> wrote in message
> news:ACFB2214-1B3A-4794-B5ED-FE8B55D0B167@.microsoft.com...
>