Information needed on jobs !

Hi
I please need your help on jobs. I am new to it !
For all our world wide customers, I need to have a sql
script that will create a job to be run on each production
database. This will just call a stored procedure that
will update data in that DB.
1) what minimum permissions or roles are needed to create
a job ?
2) NB NB:: can a job be scheduled to run based on the
results of a sql stamenent ?
E.g. run every getdate() + (select no_of_days from .....)
Your help is appreciated immensely !!
Thanks
Tania1. Anybody in public role can create a job.
2. I am not sure if I understood this correctly or not. You can write a
cursor/loop to iterate through each rows in your resultset and call the
sp_add_jobschedule/sp_update_jobschedule procedures. If you are asking about
running a job, you can use the sp_start_job stored procedure. All details
regarding these procedures can be found in SQL Server Books Online.
--
- Anith
( Please reply to newsgroups only )

INFO/SUGGESTIONS Please : SQL performance (fragmented disk)

I'm a developer at my company, but I've worked with hardware quite abit at my last job. I'm finding it hard to talk to one of our system admins here.

I'm running into what looks like disk issues on our SQL Server, I know the DB files all reside on a large SCSI Raid, the only files on the RAID are the DB files, no OS or program files.

Also the disks have never been defragmented, he wants to say :

1. SCSI and RAID eliminate the impact of fragmentation.
2. SQL doesn't get impacted by physical fragmentation.

I know both to be false statements but don't want to start an argument, nor go over his head.

I would like to "find" some reputable articles dealing with disk fragmentation and SQL(database) performance..

If anyone has a good site that displays good information I would greatly appreciate it.

OR

If anyone has some personal experience with issues like this, please share them..

You may want to read the following white paper: 'Microsoft SQL Server 2000 Index Defragmentation Best Practices' (http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx), which may give you more idea about fragmentation.

Thanks

Stephen

Info about a running job step

Hi group,
I need to retrieve information about a running step, specifically its
status. When a step is being executed, the EM always knows and shows so
(under status showing Executing Job Step 'n (step name)'). However, I can
not find such information in the system tables. where does EM get the info
from? How can I access this info with a query, or better yet, within a
stored proc? Help is appreciated.
QuentinYou can use sp_help_job e.g.
exec msdb..sp_help_job
@.job_name = 'jobname ,
@.job_aspect = 'JOB'
Look at the current_execution_status and current_execution_step columns
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Quentin Ran" <ab@.who.com> wrote in message
news:OxXqrA3VDHA.612@.TK2MSFTNGP10.phx.gbl...
Hi group,
I need to retrieve information about a running step, specifically its
status. When a step is being executed, the EM always knows and shows so
(under status showing Executing Job Step 'n (step name)'). However, I can
not find such information in the system tables. where does EM get the info
from? How can I access this info with a query, or better yet, within a
stored proc? Help is appreciated.
Quentin|||Thanks Mr. Dentist.
"Jasper Smith" <jasper_smith9@.hotmail.com> wrote in message
news:efTLfj4VDHA.1816@.TK2MSFTNGP09.phx.gbl...
> You can use sp_help_job e.g.
> exec msdb..sp_help_job
> @.job_name = 'jobname ,
> @.job_aspect = 'JOB'
> Look at the current_execution_status and current_execution_step columns
> --
> HTH
> Jasper Smith (SQL Server MVP)
> I support PASS - the definitive, global
> community for SQL Server professionals -
> http://www.sqlpass.org
>
> "Quentin Ran" <ab@.who.com> wrote in message
> news:OxXqrA3VDHA.612@.TK2MSFTNGP10.phx.gbl...
> Hi group,
> I need to retrieve information about a running step, specifically its
> status. When a step is being executed, the EM always knows and shows so
> (under status showing Executing Job Step 'n (step name)'). However, I can
> not find such information in the system tables. where does EM get the
info
> from? How can I access this info with a query, or better yet, within a
> stored proc? Help is appreciated.
> Quentin
>

Indexing....

Is it possible to schedule indexing?
I am loading the data from flat file to table every day night from a
scheduled job.
After loading the data I would like to index the table so that search
becomes very fast.
I am using SQL2K.
Thanks,
Joan AlexJoan Alex wrote:
> Is it possible to schedule indexing?
> I am loading the data from flat file to table every day night from a
> scheduled job.
> After loading the data I would like to index the table so that search
> becomes very fast.
> I am using SQL2K.
> Thanks,
> Joan Alex
If you are already scheduling the job to import the data, why can't you
add the indexing to the end of that batch? Or as a new step in the job?
You can easily add a new step to the job that runs after the successful
completion of the first "import" step.
David Gugick
Imceda Software
www.imceda.com|||What you are saying is
1. Call the CREATE index STATEMENT after loading the data.
2. Do I have to drop the index before creating the index with the same name.
I can check this in the documenation. Just asked.
Thanks,
Joan
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
> Joan Alex wrote:
> If you are already scheduling the job to import the data, why can't you
> add the indexing to the end of that batch? Or as a new step in the job?
> You can easily add a new step to the job that runs after the successful
> completion of the first "import" step.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>|||Joan Alex wrote:[vbcol=seagreen]
> What you are saying is
> 1. Call the CREATE index STATEMENT after loading the data.
> 2. Do I have to drop the index before creating the index with the
> same name. I can check this in the documenation. Just asked.
> Thanks,
> Joan
>
> "David Gugick" <davidg-nospam@.imceda.com> wrote in message
> news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
You can use the WITH DROP EXISTING clause in the CREATE INDEX statement
to force SQL Server to drop it for you. It also has other benefits. Just
run it on the clustered index on the table and you should be set.
David Gugick
Imceda Software
www.imceda.com|||How many rows are you importing and are there rows already in the table?
You may be better off dropping the indexes before you import and then
creating them again after the import.
Andrew J. Kelly SQL MVP
"Joan Alex" <JAlex45@.hotmail.com> wrote in message
news:ON2IAAs7EHA.1260@.TK2MSFTNGP12.phx.gbl...
> What you are saying is
> 1. Call the CREATE index STATEMENT after loading the data.
> 2. Do I have to drop the index before creating the index with the same
> name.
> I can check this in the documenation. Just asked.
> Thanks,
> Joan
>
> "David Gugick" <davidg-nospam@.imceda.com> wrote in message
> news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
>|||Everyday nightly scheduled job truncates the table and loads the data. The
data will be around 2 milllion records every day.
Do you suggest drop the index first, truncate the table, load the data from
the flatfile and build the index.
Thanks,
Joan
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eqJDO4s7EHA.1392@.tk2msftngp13.phx.gbl...
> How many rows are you importing and are there rows already in the table?
> You may be better off dropping the indexes before you import and then
> creating them again after the import.
> --
> Andrew J. Kelly SQL MVP
>
> "Joan Alex" <JAlex45@.hotmail.com> wrote in message
> news:ON2IAAs7EHA.1260@.TK2MSFTNGP12.phx.gbl...
>|||It can depend but I would Truncate it first in any case. Then you should
test a few ways to see which gives the best performance in regards to
importing with the indexes intact or removed. The Clustered index can
usually be the most significant factor but you usually can get faster
overall times by dropping them, importing and then creating. If the
Clustered index is on a monotonically increasing column such as Identity or
a Datetime that will be imported in chronological order you might want to
leave the clustered index intact and drop the non-clustered ones. If it's
on a column that has a fairly random value you might be best to remove it
before importing. Always create the clustered index first before creating
any nonclustered ones. You should also see if you can do a "minimally
logged bulk load" for even faster performance. See "minimally logged bulk
copy" in BooksOnLine for details on what you need to accomplish that.
Andrew J. Kelly SQL MVP
"Joan Alex" <JAlex45@.hotmail.com> wrote in message
news:%23fB4S%23s7EHA.2516@.TK2MSFTNGP09.phx.gbl...
> Everyday nightly scheduled job truncates the table and loads the data. The
> data will be around 2 milllion records every day.
> Do you suggest drop the index first, truncate the table, load the data
> from
> the flatfile and build the index.
> Thanks,
> Joan
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eqJDO4s7EHA.1392@.tk2msftngp13.phx.gbl...
>

Indexing....

Is it possible to schedule indexing?
I am loading the data from flat file to table every day night from a
scheduled job.
After loading the data I would like to index the table so that search
becomes very fast.
I am using SQL2K.
Thanks,
Joan Alex
Joan Alex wrote:
> Is it possible to schedule indexing?
> I am loading the data from flat file to table every day night from a
> scheduled job.
> After loading the data I would like to index the table so that search
> becomes very fast.
> I am using SQL2K.
> Thanks,
> Joan Alex
If you are already scheduling the job to import the data, why can't you
add the indexing to the end of that batch? Or as a new step in the job?
You can easily add a new step to the job that runs after the successful
completion of the first "import" step.
David Gugick
Imceda Software
www.imceda.com
|||What you are saying is
1. Call the CREATE index STATEMENT after loading the data.
2. Do I have to drop the index before creating the index with the same name.
I can check this in the documenation. Just asked.
Thanks,
Joan
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
> Joan Alex wrote:
> If you are already scheduling the job to import the data, why can't you
> add the indexing to the end of that batch? Or as a new step in the job?
> You can easily add a new step to the job that runs after the successful
> completion of the first "import" step.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>
|||Joan Alex wrote:[vbcol=seagreen]
> What you are saying is
> 1. Call the CREATE index STATEMENT after loading the data.
> 2. Do I have to drop the index before creating the index with the
> same name. I can check this in the documenation. Just asked.
> Thanks,
> Joan
>
> "David Gugick" <davidg-nospam@.imceda.com> wrote in message
> news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
You can use the WITH DROP EXISTING clause in the CREATE INDEX statement
to force SQL Server to drop it for you. It also has other benefits. Just
run it on the clustered index on the table and you should be set.
David Gugick
Imceda Software
www.imceda.com
|||How many rows are you importing and are there rows already in the table?
You may be better off dropping the indexes before you import and then
creating them again after the import.
Andrew J. Kelly SQL MVP
"Joan Alex" <JAlex45@.hotmail.com> wrote in message
news:ON2IAAs7EHA.1260@.TK2MSFTNGP12.phx.gbl...
> What you are saying is
> 1. Call the CREATE index STATEMENT after loading the data.
> 2. Do I have to drop the index before creating the index with the same
> name.
> I can check this in the documenation. Just asked.
> Thanks,
> Joan
>
> "David Gugick" <davidg-nospam@.imceda.com> wrote in message
> news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
>
|||Everyday nightly scheduled job truncates the table and loads the data. The
data will be around 2 milllion records every day.
Do you suggest drop the index first, truncate the table, load the data from
the flatfile and build the index.
Thanks,
Joan
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eqJDO4s7EHA.1392@.tk2msftngp13.phx.gbl...
> How many rows are you importing and are there rows already in the table?
> You may be better off dropping the indexes before you import and then
> creating them again after the import.
> --
> Andrew J. Kelly SQL MVP
>
> "Joan Alex" <JAlex45@.hotmail.com> wrote in message
> news:ON2IAAs7EHA.1260@.TK2MSFTNGP12.phx.gbl...
>
|||It can depend but I would Truncate it first in any case. Then you should
test a few ways to see which gives the best performance in regards to
importing with the indexes intact or removed. The Clustered index can
usually be the most significant factor but you usually can get faster
overall times by dropping them, importing and then creating. If the
Clustered index is on a monotonically increasing column such as Identity or
a Datetime that will be imported in chronological order you might want to
leave the clustered index intact and drop the non-clustered ones. If it's
on a column that has a fairly random value you might be best to remove it
before importing. Always create the clustered index first before creating
any nonclustered ones. You should also see if you can do a "minimally
logged bulk load" for even faster performance. See "minimally logged bulk
copy" in BooksOnLine for details on what you need to accomplish that.
Andrew J. Kelly SQL MVP
"Joan Alex" <JAlex45@.hotmail.com> wrote in message
news:%23fB4S%23s7EHA.2516@.TK2MSFTNGP09.phx.gbl...
> Everyday nightly scheduled job truncates the table and loads the data. The
> data will be around 2 milllion records every day.
> Do you suggest drop the index first, truncate the table, load the data
> from
> the flatfile and build the index.
> Thanks,
> Joan
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eqJDO4s7EHA.1392@.tk2msftngp13.phx.gbl...
>
sql

Indexing....

Is it possible to schedule indexing?
I am loading the data from flat file to table every day night from a
scheduled job.
After loading the data I would like to index the table so that search
becomes very fast.
I am using SQL2K.
Thanks,
Joan AlexJoan Alex wrote:
> Is it possible to schedule indexing?
> I am loading the data from flat file to table every day night from a
> scheduled job.
> After loading the data I would like to index the table so that search
> becomes very fast.
> I am using SQL2K.
> Thanks,
> Joan Alex
If you are already scheduling the job to import the data, why can't you
add the indexing to the end of that batch? Or as a new step in the job?
You can easily add a new step to the job that runs after the successful
completion of the first "import" step.
David Gugick
Imceda Software
www.imceda.com|||What you are saying is
1. Call the CREATE index STATEMENT after loading the data.
2. Do I have to drop the index before creating the index with the same name.
I can check this in the documenation. Just asked.
Thanks,
Joan
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
> Joan Alex wrote:
> > Is it possible to schedule indexing?
> >
> > I am loading the data from flat file to table every day night from a
> > scheduled job.
> >
> > After loading the data I would like to index the table so that search
> > becomes very fast.
> >
> > I am using SQL2K.
> >
> > Thanks,
> >
> > Joan Alex
> If you are already scheduling the job to import the data, why can't you
> add the indexing to the end of that batch? Or as a new step in the job?
> You can easily add a new step to the job that runs after the successful
> completion of the first "import" step.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com
>|||Joan Alex wrote:
> What you are saying is
> 1. Call the CREATE index STATEMENT after loading the data.
> 2. Do I have to drop the index before creating the index with the
> same name. I can check this in the documenation. Just asked.
> Thanks,
> Joan
>
> "David Gugick" <davidg-nospam@.imceda.com> wrote in message
> news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
>> Joan Alex wrote:
>> Is it possible to schedule indexing?
>> I am loading the data from flat file to table every day night from a
>> scheduled job.
>> After loading the data I would like to index the table so that
>> search becomes very fast.
>> I am using SQL2K.
>> Thanks,
>> Joan Alex
>> If you are already scheduling the job to import the data, why can't
>> you add the indexing to the end of that batch? Or as a new step in
>> the job?
>> You can easily add a new step to the job that runs after the
>> successful completion of the first "import" step.
>>
>> --
>> David Gugick
>> Imceda Software
>> www.imceda.com
You can use the WITH DROP EXISTING clause in the CREATE INDEX statement
to force SQL Server to drop it for you. It also has other benefits. Just
run it on the clustered index on the table and you should be set.
--
David Gugick
Imceda Software
www.imceda.com|||How many rows are you importing and are there rows already in the table?
You may be better off dropping the indexes before you import and then
creating them again after the import.
--
Andrew J. Kelly SQL MVP
"Joan Alex" <JAlex45@.hotmail.com> wrote in message
news:ON2IAAs7EHA.1260@.TK2MSFTNGP12.phx.gbl...
> What you are saying is
> 1. Call the CREATE index STATEMENT after loading the data.
> 2. Do I have to drop the index before creating the index with the same
> name.
> I can check this in the documenation. Just asked.
> Thanks,
> Joan
>
> "David Gugick" <davidg-nospam@.imceda.com> wrote in message
> news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
>> Joan Alex wrote:
>> > Is it possible to schedule indexing?
>> >
>> > I am loading the data from flat file to table every day night from a
>> > scheduled job.
>> >
>> > After loading the data I would like to index the table so that search
>> > becomes very fast.
>> >
>> > I am using SQL2K.
>> >
>> > Thanks,
>> >
>> > Joan Alex
>> If you are already scheduling the job to import the data, why can't you
>> add the indexing to the end of that batch? Or as a new step in the job?
>> You can easily add a new step to the job that runs after the successful
>> completion of the first "import" step.
>>
>> --
>> David Gugick
>> Imceda Software
>> www.imceda.com
>|||Everyday nightly scheduled job truncates the table and loads the data. The
data will be around 2 milllion records every day.
Do you suggest drop the index first, truncate the table, load the data from
the flatfile and build the index.
Thanks,
Joan
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:eqJDO4s7EHA.1392@.tk2msftngp13.phx.gbl...
> How many rows are you importing and are there rows already in the table?
> You may be better off dropping the indexes before you import and then
> creating them again after the import.
> --
> Andrew J. Kelly SQL MVP
>
> "Joan Alex" <JAlex45@.hotmail.com> wrote in message
> news:ON2IAAs7EHA.1260@.TK2MSFTNGP12.phx.gbl...
> > What you are saying is
> > 1. Call the CREATE index STATEMENT after loading the data.
> > 2. Do I have to drop the index before creating the index with the same
> > name.
> > I can check this in the documenation. Just asked.
> > Thanks,
> > Joan
> >
> >
> >
> > "David Gugick" <davidg-nospam@.imceda.com> wrote in message
> > news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
> >> Joan Alex wrote:
> >> > Is it possible to schedule indexing?
> >> >
> >> > I am loading the data from flat file to table every day night from a
> >> > scheduled job.
> >> >
> >> > After loading the data I would like to index the table so that search
> >> > becomes very fast.
> >> >
> >> > I am using SQL2K.
> >> >
> >> > Thanks,
> >> >
> >> > Joan Alex
> >>
> >> If you are already scheduling the job to import the data, why can't you
> >> add the indexing to the end of that batch? Or as a new step in the job?
> >>
> >> You can easily add a new step to the job that runs after the successful
> >> completion of the first "import" step.
> >>
> >>
> >> --
> >> David Gugick
> >> Imceda Software
> >> www.imceda.com
> >>
> >
> >
>|||It can depend but I would Truncate it first in any case. Then you should
test a few ways to see which gives the best performance in regards to
importing with the indexes intact or removed. The Clustered index can
usually be the most significant factor but you usually can get faster
overall times by dropping them, importing and then creating. If the
Clustered index is on a monotonically increasing column such as Identity or
a Datetime that will be imported in chronological order you might want to
leave the clustered index intact and drop the non-clustered ones. If it's
on a column that has a fairly random value you might be best to remove it
before importing. Always create the clustered index first before creating
any nonclustered ones. You should also see if you can do a "minimally
logged bulk load" for even faster performance. See "minimally logged bulk
copy" in BooksOnLine for details on what you need to accomplish that.
Andrew J. Kelly SQL MVP
"Joan Alex" <JAlex45@.hotmail.com> wrote in message
news:%23fB4S%23s7EHA.2516@.TK2MSFTNGP09.phx.gbl...
> Everyday nightly scheduled job truncates the table and loads the data. The
> data will be around 2 milllion records every day.
> Do you suggest drop the index first, truncate the table, load the data
> from
> the flatfile and build the index.
> Thanks,
> Joan
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:eqJDO4s7EHA.1392@.tk2msftngp13.phx.gbl...
>> How many rows are you importing and are there rows already in the table?
>> You may be better off dropping the indexes before you import and then
>> creating them again after the import.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Joan Alex" <JAlex45@.hotmail.com> wrote in message
>> news:ON2IAAs7EHA.1260@.TK2MSFTNGP12.phx.gbl...
>> > What you are saying is
>> > 1. Call the CREATE index STATEMENT after loading the data.
>> > 2. Do I have to drop the index before creating the index with the same
>> > name.
>> > I can check this in the documenation. Just asked.
>> > Thanks,
>> > Joan
>> >
>> >
>> >
>> > "David Gugick" <davidg-nospam@.imceda.com> wrote in message
>> > news:uUzT9pr7EHA.1408@.TK2MSFTNGP10.phx.gbl...
>> >> Joan Alex wrote:
>> >> > Is it possible to schedule indexing?
>> >> >
>> >> > I am loading the data from flat file to table every day night from a
>> >> > scheduled job.
>> >> >
>> >> > After loading the data I would like to index the table so that
>> >> > search
>> >> > becomes very fast.
>> >> >
>> >> > I am using SQL2K.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Joan Alex
>> >>
>> >> If you are already scheduling the job to import the data, why can't
>> >> you
>> >> add the indexing to the end of that batch? Or as a new step in the
>> >> job?
>> >>
>> >> You can easily add a new step to the job that runs after the
>> >> successful
>> >> completion of the first "import" step.
>> >>
>> >>
>> >> --
>> >> David Gugick
>> >> Imceda Software
>> >> www.imceda.com
>> >>
>> >
>> >
>>
>

Indexing job interferes with log shipping

The log shipping job fails right after indexing runs and the log file itself
turns up corrupt. Is it possible to run a command that temporarily disables
the log shipping while indexing runs and then upon completion of the indexing
(fail or not) re-enable the log-shipping job?
Regards,
Jamie
No, but it is recommended that you switch to bulk logged recovery model
before starting indexing as the log size is smaller.
Return to full after you have completed the indexing operation.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:84589C1C-6598-4985-81F8-61A68813EA7D@.microsoft.com...
> The log shipping job fails right after indexing runs and the log file
> itself
> turns up corrupt. Is it possible to run a command that temporarily
> disables
> the log shipping while indexing runs and then upon completion of the
> indexing
> (fail or not) re-enable the log-shipping job?
> --
> Regards,
> Jamie
|||Paul,
I think I should have mentioned that this is partially a Red Gate error:
Data decompression error: Access violation at address 0050BA10 in
module'SQBCoreService.exe'. Read of address 7FF80000 Process terminated
unexpectedly. Error code: -2139684860
AND ON THE Application Level...
The description for Event ID '-1073724769' in Source 'MSSQLSERVER' cannot be
found. The local computer may not have the necessary registry information or
message DLL files to display the message, or you may not have permission to
access them. The following information is part of the event:'18210',
'BackupVirtualDeviceSet::Initialize: Open failure on backup device
'SQLBACKUP_C2F85077-1436-4FC9-BBD0-7B4ECC822724'. Operating system error
0x80070002(The system cannot find the file specified.).
Red Gate suspects that this happens when the decompression routine is
running its copy operation. I didn't know this when I asked the question.
I thought it might be something to do with a locking issue but Hilary gave me
enough information for me to figure it out by myself.
Instead of trying to alter the logging job, I alter the indexing job to
switch to BULK_LOGGING mode and then return to FULL when the indexing is
done. Will let you know next week if it works or not.
Jamie
Regards,
Jamie
"Paul Ibison" wrote:

> Jamie - how does the log file 'turn up corrupt' - can you post any error
> message you're seeing.
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
>
>