Hello. When you turn Logging on, for a DTS package, it
appears to save the history forever? If that's true, is
there an option to clear DTS package logs, after like 30
days? or would you need to write something to do this
purge manually? THanks, BruceYou can delete all the logs for a package from the Package Properties,
Logging tab.
You can also right click on local packages under the DTS node in
Enterprise Manager and select Logging. From here you have a bit more
control on selecting packages, selecting logs to delete, etc.
If you want to automate this somehow, you could code your own
maintenance of these using the DTS Object Model and schedule this
through a job. Take a look at the RemovePackageLogRecords method of
the PackageSQLServer object.
-Sue
On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
<bruce@.defreitas.com> wrote:
>Hello. When you turn Logging on, for a DTS package, it
>appears to save the history forever? If that's true, is
>there an option to clear DTS package logs, after like 30
>days? or would you need to write something to do this
>purge manually? THanks, Bruce|||THanks Sue. Yes, I was looking for an option hopefully
built-in to SQL Server, to give me a set number of logs,
or a set number of days, like you can adjust the number of
SQL error log files. Yep, I'll check out the homegrown
approach... THanks, Bruce
>--Original Message--
>You can delete all the logs for a package from the
Package Properties,
>Logging tab.
>You can also right click on local packages under the DTS
node in
>Enterprise Manager and select Logging. From here you have
a bit more
>control on selecting packages, selecting logs to delete,
etc.
>If you want to automate this somehow, you could code your
own
>maintenance of these using the DTS Object Model and
schedule this
>through a job. Take a look at the
RemovePackageLogRecords method of
>the PackageSQLServer object.
>-Sue
>On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
><bruce@.defreitas.com> wrote:
>
>.
>
Showing posts with label forever. Show all posts
Showing posts with label forever. Show all posts
Monday, March 19, 2012
DTS Package Logging - can u limit it?
Hello. When you turn Logging on, for a DTS package, it
appears to save the history forever? If that's true, is
there an option to clear DTS package logs, after like 30
days? or would you need to write something to do this
purge manually? THanks, Bruce
You can delete all the logs for a package from the Package Properties,
Logging tab.
You can also right click on local packages under the DTS node in
Enterprise Manager and select Logging. From here you have a bit more
control on selecting packages, selecting logs to delete, etc.
If you want to automate this somehow, you could code your own
maintenance of these using the DTS Object Model and schedule this
through a job. Take a look at the RemovePackageLogRecords method of
the PackageSQLServer object.
-Sue
On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
<bruce@.defreitas.com> wrote:
>Hello. When you turn Logging on, for a DTS package, it
>appears to save the history forever? If that's true, is
>there an option to clear DTS package logs, after like 30
>days? or would you need to write something to do this
>purge manually? THanks, Bruce
|||THanks Sue. Yes, I was looking for an option hopefully
built-in to SQL Server, to give me a set number of logs,
or a set number of days, like you can adjust the number of
SQL error log files. Yep, I'll check out the homegrown
approach... THanks, Bruce
>--Original Message--
>You can delete all the logs for a package from the
Package Properties,
>Logging tab.
>You can also right click on local packages under the DTS
node in
>Enterprise Manager and select Logging. From here you have
a bit more
>control on selecting packages, selecting logs to delete,
etc.
>If you want to automate this somehow, you could code your
own
>maintenance of these using the DTS Object Model and
schedule this
>through a job. Take a look at the
RemovePackageLogRecords method of
>the PackageSQLServer object.
>-Sue
>On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
><bruce@.defreitas.com> wrote:
>
>.
>
appears to save the history forever? If that's true, is
there an option to clear DTS package logs, after like 30
days? or would you need to write something to do this
purge manually? THanks, Bruce
You can delete all the logs for a package from the Package Properties,
Logging tab.
You can also right click on local packages under the DTS node in
Enterprise Manager and select Logging. From here you have a bit more
control on selecting packages, selecting logs to delete, etc.
If you want to automate this somehow, you could code your own
maintenance of these using the DTS Object Model and schedule this
through a job. Take a look at the RemovePackageLogRecords method of
the PackageSQLServer object.
-Sue
On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
<bruce@.defreitas.com> wrote:
>Hello. When you turn Logging on, for a DTS package, it
>appears to save the history forever? If that's true, is
>there an option to clear DTS package logs, after like 30
>days? or would you need to write something to do this
>purge manually? THanks, Bruce
|||THanks Sue. Yes, I was looking for an option hopefully
built-in to SQL Server, to give me a set number of logs,
or a set number of days, like you can adjust the number of
SQL error log files. Yep, I'll check out the homegrown
approach... THanks, Bruce
>--Original Message--
>You can delete all the logs for a package from the
Package Properties,
>Logging tab.
>You can also right click on local packages under the DTS
node in
>Enterprise Manager and select Logging. From here you have
a bit more
>control on selecting packages, selecting logs to delete,
etc.
>If you want to automate this somehow, you could code your
own
>maintenance of these using the DTS Object Model and
schedule this
>through a job. Take a look at the
RemovePackageLogRecords method of
>the PackageSQLServer object.
>-Sue
>On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
><bruce@.defreitas.com> wrote:
>
>.
>
DTS Package Logging - can u limit it?
Hello. When you turn Logging on, for a DTS package, it
appears to save the history forever? If that's true, is
there an option to clear DTS package logs, after like 30
days? or would you need to write something to do this
purge manually? THanks, BruceYou can delete all the logs for a package from the Package Properties,
Logging tab.
You can also right click on local packages under the DTS node in
Enterprise Manager and select Logging. From here you have a bit more
control on selecting packages, selecting logs to delete, etc.
If you want to automate this somehow, you could code your own
maintenance of these using the DTS Object Model and schedule this
through a job. Take a look at the RemovePackageLogRecords method of
the PackageSQLServer object.
-Sue
On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
<bruce@.defreitas.com> wrote:
>Hello. When you turn Logging on, for a DTS package, it
>appears to save the history forever? If that's true, is
>there an option to clear DTS package logs, after like 30
>days? or would you need to write something to do this
>purge manually? THanks, Bruce|||THanks Sue. Yes, I was looking for an option hopefully
built-in to SQL Server, to give me a set number of logs,
or a set number of days, like you can adjust the number of
SQL error log files. Yep, I'll check out the homegrown
approach... THanks, Bruce
>--Original Message--
>You can delete all the logs for a package from the
Package Properties,
>Logging tab.
>You can also right click on local packages under the DTS
node in
>Enterprise Manager and select Logging. From here you have
a bit more
>control on selecting packages, selecting logs to delete,
etc.
>If you want to automate this somehow, you could code your
own
>maintenance of these using the DTS Object Model and
schedule this
>through a job. Take a look at the
RemovePackageLogRecords method of
>the PackageSQLServer object.
>-Sue
>On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
><bruce@.defreitas.com> wrote:
>>Hello. When you turn Logging on, for a DTS package, it
>>appears to save the history forever? If that's true, is
>>there an option to clear DTS package logs, after like 30
>>days? or would you need to write something to do this
>>purge manually? THanks, Bruce
>.
>
appears to save the history forever? If that's true, is
there an option to clear DTS package logs, after like 30
days? or would you need to write something to do this
purge manually? THanks, BruceYou can delete all the logs for a package from the Package Properties,
Logging tab.
You can also right click on local packages under the DTS node in
Enterprise Manager and select Logging. From here you have a bit more
control on selecting packages, selecting logs to delete, etc.
If you want to automate this somehow, you could code your own
maintenance of these using the DTS Object Model and schedule this
through a job. Take a look at the RemovePackageLogRecords method of
the PackageSQLServer object.
-Sue
On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
<bruce@.defreitas.com> wrote:
>Hello. When you turn Logging on, for a DTS package, it
>appears to save the history forever? If that's true, is
>there an option to clear DTS package logs, after like 30
>days? or would you need to write something to do this
>purge manually? THanks, Bruce|||THanks Sue. Yes, I was looking for an option hopefully
built-in to SQL Server, to give me a set number of logs,
or a set number of days, like you can adjust the number of
SQL error log files. Yep, I'll check out the homegrown
approach... THanks, Bruce
>--Original Message--
>You can delete all the logs for a package from the
Package Properties,
>Logging tab.
>You can also right click on local packages under the DTS
node in
>Enterprise Manager and select Logging. From here you have
a bit more
>control on selecting packages, selecting logs to delete,
etc.
>If you want to automate this somehow, you could code your
own
>maintenance of these using the DTS Object Model and
schedule this
>through a job. Take a look at the
RemovePackageLogRecords method of
>the PackageSQLServer object.
>-Sue
>On Fri, 29 Oct 2004 10:23:48 -0700, "Bruce de Freitas"
><bruce@.defreitas.com> wrote:
>>Hello. When you turn Logging on, for a DTS package, it
>>appears to save the history forever? If that's true, is
>>there an option to clear DTS package logs, after like 30
>>days? or would you need to write something to do this
>>purge manually? THanks, Bruce
>.
>
Friday, February 24, 2012
DTS Job Runs Forever
I can manually run a DTS package from SQL Server 2000 where the data
source is an Oracle database. Run it manually and it completes in a
few seconds. When I try to run it as a job it runs forever.
I read other posts suggesting that the SQLAgentCmdExec needs to be a
user on the Oracle server (Sun box). Why is that if the ODBC
connection already authenticates the connection? This is what is
confusing IAW Q269074.
Thanks for any suggestions.
RBollinger
The most common causes of a package running ok manually but failing as a job
are either security or environment related. When you run the package
manually, are you doing so on your PC or on the SQL Server (directly or via
Remote Desktop)? The Windows security context isn't usually an issue for
the Oracle connection, although it might be a factor for other resources
need by the package.
Hope this helps.
Dan Guzman
SQL Server MVP
"robboll" <robboll@.hotmail.com> wrote in message
news:1159215526.092875.48620@.i3g2000cwc.googlegrou ps.com...
>I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
>
|||I found the solution:
To correct the problem I installed SQL Server Service Pack 4. That's
it.
robboll wrote:
> I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
source is an Oracle database. Run it manually and it completes in a
few seconds. When I try to run it as a job it runs forever.
I read other posts suggesting that the SQLAgentCmdExec needs to be a
user on the Oracle server (Sun box). Why is that if the ODBC
connection already authenticates the connection? This is what is
confusing IAW Q269074.
Thanks for any suggestions.
RBollinger
The most common causes of a package running ok manually but failing as a job
are either security or environment related. When you run the package
manually, are you doing so on your PC or on the SQL Server (directly or via
Remote Desktop)? The Windows security context isn't usually an issue for
the Oracle connection, although it might be a factor for other resources
need by the package.
Hope this helps.
Dan Guzman
SQL Server MVP
"robboll" <robboll@.hotmail.com> wrote in message
news:1159215526.092875.48620@.i3g2000cwc.googlegrou ps.com...
>I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
>
|||I found the solution:
To correct the problem I installed SQL Server Service Pack 4. That's
it.
robboll wrote:
> I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
DTS Job Runs Forever
I can manually run a DTS package from SQL Server 2000 where the data
source is an Oracle database. Run it manually and it completes in a
few seconds. When I try to run it as a job it runs forever.
I read other posts suggesting that the SQLAgentCmdExec needs to be a
user on the Oracle server (Sun box). Why is that if the ODBC
connection already authenticates the connection? This is what is
confusing IAW Q269074.
Thanks for any suggestions.
RBollingerThe most common causes of a package running ok manually but failing as a job
are either security or environment related. When you run the package
manually, are you doing so on your PC or on the SQL Server (directly or via
Remote Desktop)? The Windows security context isn't usually an issue for
the Oracle connection, although it might be a factor for other resources
need by the package.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"robboll" <robboll@.hotmail.com> wrote in message
news:1159215526.092875.48620@.i3g2000cwc.googlegroups.com...
>I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
>|||I found the solution:
To correct the problem I installed SQL Server Service Pack 4. That's
it.
robboll wrote:
> I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
source is an Oracle database. Run it manually and it completes in a
few seconds. When I try to run it as a job it runs forever.
I read other posts suggesting that the SQLAgentCmdExec needs to be a
user on the Oracle server (Sun box). Why is that if the ODBC
connection already authenticates the connection? This is what is
confusing IAW Q269074.
Thanks for any suggestions.
RBollingerThe most common causes of a package running ok manually but failing as a job
are either security or environment related. When you run the package
manually, are you doing so on your PC or on the SQL Server (directly or via
Remote Desktop)? The Windows security context isn't usually an issue for
the Oracle connection, although it might be a factor for other resources
need by the package.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"robboll" <robboll@.hotmail.com> wrote in message
news:1159215526.092875.48620@.i3g2000cwc.googlegroups.com...
>I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
>|||I found the solution:
To correct the problem I installed SQL Server Service Pack 4. That's
it.
robboll wrote:
> I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
DTS Job Runs Forever
I can manually run a DTS package from SQL Server 2000 where the data
source is an Oracle database. Run it manually and it completes in a
few seconds. When I try to run it as a job it runs forever.
I read other posts suggesting that the SQLAgentCmdExec needs to be a
user on the Oracle server (Sun box). Why is that if the ODBC
connection already authenticates the connection? This is what is
confusing IAW Q269074.
Thanks for any suggestions.
RBollingerThe most common causes of a package running ok manually but failing as a job
are either security or environment related. When you run the package
manually, are you doing so on your PC or on the SQL Server (directly or via
Remote Desktop)? The Windows security context isn't usually an issue for
the Oracle connection, although it might be a factor for other resources
need by the package.
Hope this helps.
Dan Guzman
SQL Server MVP
"robboll" <robboll@.hotmail.com> wrote in message
news:1159215526.092875.48620@.i3g2000cwc.googlegroups.com...
>I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
>|||I found the solution:
To correct the problem I installed SQL Server Service Pack 4. That's
it.
robboll wrote:
> I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
source is an Oracle database. Run it manually and it completes in a
few seconds. When I try to run it as a job it runs forever.
I read other posts suggesting that the SQLAgentCmdExec needs to be a
user on the Oracle server (Sun box). Why is that if the ODBC
connection already authenticates the connection? This is what is
confusing IAW Q269074.
Thanks for any suggestions.
RBollingerThe most common causes of a package running ok manually but failing as a job
are either security or environment related. When you run the package
manually, are you doing so on your PC or on the SQL Server (directly or via
Remote Desktop)? The Windows security context isn't usually an issue for
the Oracle connection, although it might be a factor for other resources
need by the package.
Hope this helps.
Dan Guzman
SQL Server MVP
"robboll" <robboll@.hotmail.com> wrote in message
news:1159215526.092875.48620@.i3g2000cwc.googlegroups.com...
>I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
>|||I found the solution:
To correct the problem I installed SQL Server Service Pack 4. That's
it.
robboll wrote:
> I can manually run a DTS package from SQL Server 2000 where the data
> source is an Oracle database. Run it manually and it completes in a
> few seconds. When I try to run it as a job it runs forever.
> I read other posts suggesting that the SQLAgentCmdExec needs to be a
> user on the Oracle server (Sun box). Why is that if the ODBC
> connection already authenticates the connection? This is what is
> confusing IAW Q269074.
> Thanks for any suggestions.
> RBollinger
Subscribe to:
Posts (Atom)