Tuesday, March 27, 2012
DTS Question ...
I be able to use DTS from this machine if we upgrade to SQL 2005 on the
server; the reason I'm asking is that I think the "upgrade" (with Small
Business Server) is going to be to the Workgroup Edition, which I don't
think has DTS in the box ... or does it ?
Thanks in advance ...
LLiz wrote:
> I have SQL 2000 Enterprise Manager on a desktop development machine .. wil
l
> I be able to use DTS from this machine if we upgrade to SQL 2005 on the
> server; the reason I'm asking is that I think the "upgrade" (with Small
> Business Server) is going to be to the Workgroup Edition, which I don't
> think has DTS in the box ... or does it ?
> Thanks in advance ...
> L
>
>
DTS no longer exists in SQL Server, it is replaced with Integration
Services in SQL 2005.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:eYtkiBIpGHA.220@.TK2MSFTNGP05.phx.gbl...
> Liz wrote:
will[vbcol=seagreen]
> DTS no longer exists in SQL Server, it is replaced with Integration
> Services in SQL 2005.
yeah, but DTS exists on my desktop .. or does it ? I never once thought
about it ... is it not able to talk to SQL 2005 ? Can you use EM at all
with a SQL 2005 back end ?|||Liz wrote:
> yeah, but DTS exists on my desktop .. or does it ? I never once thought
> about it ... is it not able to talk to SQL 2005 ? Can you use EM at all
> with a SQL 2005 back end ?
>
>
No, the DTS DESIGNER exists on your desktop, the DTS engine does not,
that is a server component. And no, you'll have a hard time getting
Enterprise Manager to work with a 2005 server.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:OuYToQOpGHA.4192@.TK2MSFTNGP03.phx.gbl...
> Liz wrote:
> No, the DTS DESIGNER exists on your desktop, the DTS engine does not,
> that is a server component. And no, you'll have a hard time getting
> Enterprise Manager to work with a 2005 server.
but the on the MS site today I saw in a SQL 2005 WG ED. summary that you can
download DTS for use with it ... ' (in addition to whatever the
import/export facilities that are native to the WG Edition (and other
editions I presume))|||Liz wrote:
> "Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
> news:OuYToQOpGHA.4192@.TK2MSFTNGP03.phx.gbl...
> but the on the MS site today I saw in a SQL 2005 WG ED. summary that you c
an
> download DTS for use with it ... ' (in addition to whatever the
> import/export facilities that are native to the WG Edition (and other
> editions I presume))
>
>
You can download the DTS DESIGNER to use with the new Management Studio
- this is not the DTS engine. All this does is allow you to connect to
SQL 2000 servers to edit legacy DTS packages.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:eVabsvapGHA.4760@.TK2MSFTNGP05.phx.gbl...
can[vbcol=seagreen]
[vbcol=seagreen]
> You can download the DTS DESIGNER to use with the new Management Studio
> - this is not the DTS engine. All this does is allow you to connect to
> SQL 2000 servers to edit legacy DTS packages.
jeez ... they don't do much of a job explaining that in the feature summary
...
here's a quote:
"You can also run packages that were created by using SQL Server 2000 tools
as part of a SQL Server 2005 data transformation solution. Integration
Services provides the Execute DTS 2000 Package task for running DTS packages
from within SQL Server 2005 Integration Services packages."
http://msdn2.microsoft.com/en-us/library/ms143706.aspx
that sure makes it sound like you can run a DTS package against SQL2005 data
... it's not completely unambiguous BUT ...
Thanks, Tracy ...
L|||Liz wrote:
> jeez ... they don't do much of a job explaining that in the feature summar
y
> ...
> here's a quote:
> "You can also run packages that were created by using SQL Server 2000 tool
s
> as part of a SQL Server 2005 data transformation solution. Integration
> Services provides the Execute DTS 2000 Package task for running DTS packag
es
> from within SQL Server 2005 Integration Services packages."
> http://msdn2.microsoft.com/en-us/library/ms143706.aspx
> that sure makes it sound like you can run a DTS package against SQL2005 da
ta
> ... it's not completely unambiguous BUT ...
> Thanks, Tracy ...
> L
>
You can run an existing DTS package (imported from a SQL 2000 instance)
as a task inside an SSIS project. You can't create new DTS packages as
they existed in SQL 2000, that whole concept has been replaced with
SSIS. It's much more powerful than DTS was, you should spend some time
exploring its capabilities.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
DTS Question ...
I be able to use DTS from this machine if we upgrade to SQL 2005 on the
server; the reason I'm asking is that I think the "upgrade" (with Small
Business Server) is going to be to the Workgroup Edition, which I don't
think has DTS in the box ... or does it ?
Thanks in advance ...
LLiz wrote:
> I have SQL 2000 Enterprise Manager on a desktop development machine .. will
> I be able to use DTS from this machine if we upgrade to SQL 2005 on the
> server; the reason I'm asking is that I think the "upgrade" (with Small
> Business Server) is going to be to the Workgroup Edition, which I don't
> think has DTS in the box ... or does it ?
> Thanks in advance ...
> L
>
>
DTS no longer exists in SQL Server, it is replaced with Integration
Services in SQL 2005.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:eYtkiBIpGHA.220@.TK2MSFTNGP05.phx.gbl...
> Liz wrote:
> > I have SQL 2000 Enterprise Manager on a desktop development machine ..
will
> > I be able to use DTS from this machine if we upgrade to SQL 2005 on the
> > server; the reason I'm asking is that I think the "upgrade" (with Small
> > Business Server) is going to be to the Workgroup Edition, which I don't
> > think has DTS in the box ... or does it ?
> >
> > Thanks in advance ...
> DTS no longer exists in SQL Server, it is replaced with Integration
> Services in SQL 2005.
yeah, but DTS exists on my desktop .. or does it ? I never once thought
about it ... is it not able to talk to SQL 2005 ? Can you use EM at all
with a SQL 2005 back end ?|||Liz wrote:
> yeah, but DTS exists on my desktop .. or does it ? I never once thought
> about it ... is it not able to talk to SQL 2005 ? Can you use EM at all
> with a SQL 2005 back end ?
>
>
No, the DTS DESIGNER exists on your desktop, the DTS engine does not,
that is a server component. And no, you'll have a hard time getting
Enterprise Manager to work with a 2005 server.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:OuYToQOpGHA.4192@.TK2MSFTNGP03.phx.gbl...
> Liz wrote:
> >
> > yeah, but DTS exists on my desktop .. or does it ? I never once thought
> > about it ... is it not able to talk to SQL 2005 ? Can you use EM at all
> > with a SQL 2005 back end ?
> >
> >
> >
> No, the DTS DESIGNER exists on your desktop, the DTS engine does not,
> that is a server component. And no, you'll have a hard time getting
> Enterprise Manager to work with a 2005 server.
but the on the MS site today I saw in a SQL 2005 WG ED. summary that you can
download DTS for use with it ... ' (in addition to whatever the
import/export facilities that are native to the WG Edition (and other
editions I presume))|||Liz wrote:
> "Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
> news:OuYToQOpGHA.4192@.TK2MSFTNGP03.phx.gbl...
>> Liz wrote:
>> yeah, but DTS exists on my desktop .. or does it ? I never once thought
>> about it ... is it not able to talk to SQL 2005 ? Can you use EM at all
>> with a SQL 2005 back end ?
>>
>> No, the DTS DESIGNER exists on your desktop, the DTS engine does not,
>> that is a server component. And no, you'll have a hard time getting
>> Enterprise Manager to work with a 2005 server.
> but the on the MS site today I saw in a SQL 2005 WG ED. summary that you can
> download DTS for use with it ... ' (in addition to whatever the
> import/export facilities that are native to the WG Edition (and other
> editions I presume))
>
>
You can download the DTS DESIGNER to use with the new Management Studio
- this is not the DTS engine. All this does is allow you to connect to
SQL 2000 servers to edit legacy DTS packages.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:eVabsvapGHA.4760@.TK2MSFTNGP05.phx.gbl...
> > but the on the MS site today I saw in a SQL 2005 WG ED. summary that you
can
> > download DTS for use with it ... ' (in addition to whatever the
> > import/export facilities that are native to the WG Edition (and other
> > editions I presume))
> You can download the DTS DESIGNER to use with the new Management Studio
> - this is not the DTS engine. All this does is allow you to connect to
> SQL 2000 servers to edit legacy DTS packages.
jeez ... they don't do much of a job explaining that in the feature summary
...
here's a quote:
"You can also run packages that were created by using SQL Server 2000 tools
as part of a SQL Server 2005 data transformation solution. Integration
Services provides the Execute DTS 2000 Package task for running DTS packages
from within SQL Server 2005 Integration Services packages."
http://msdn2.microsoft.com/en-us/library/ms143706.aspx
that sure makes it sound like you can run a DTS package against SQL2005 data
... it's not completely unambiguous BUT ...
Thanks, Tracy ...
L|||Liz wrote:
> jeez ... they don't do much of a job explaining that in the feature summary
> ...
> here's a quote:
> "You can also run packages that were created by using SQL Server 2000 tools
> as part of a SQL Server 2005 data transformation solution. Integration
> Services provides the Execute DTS 2000 Package task for running DTS packages
> from within SQL Server 2005 Integration Services packages."
> http://msdn2.microsoft.com/en-us/library/ms143706.aspx
> that sure makes it sound like you can run a DTS package against SQL2005 data
> ... it's not completely unambiguous BUT ...
> Thanks, Tracy ...
> L
>
You can run an existing DTS package (imported from a SQL 2000 instance)
as a task inside an SSIS project. You can't create new DTS packages as
they existed in SQL 2000, that whole concept has been replaced with
SSIS. It's much more powerful than DTS was, you should spend some time
exploring its capabilities.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
Thursday, March 22, 2012
DTS packages backup ?
On our dev machine there are some DTS packages in the DataTransformationServices\LocalPackages. Our dev machine & DB is backed up every day (.bak file and backup of data files)
We had a crash and had to restore the DB's, now all DTS packages are gone !
We're are they saved ? Can I get them back somehow ?DTS packages stored on the server are in msdb.
-PatP|||DTS packages will be saved in MSDB database and if you're not maintained any MSDB backup then assume they are gone.
Its better and advisable to maintain regular backups for system databases too.|||Thanks for the info,
but ofcourse they didn't backup the msdb...|||aha, I found a backup of the data files,
how can I know get it back,
I tried a detach/attach of the msdb db but he refuses to detach it ?|||You probably want to read up on Restoring the model, msdb, and distribution Databases (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/ad_bkprst_2w1f.asp) before you start. There are some gotchas that you need to consider.
You'll need to use SQL Enterprise Mangler, or BACKUP DATABASE (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht_7_backpc_7cft.asp) to make a backup, then move that to the new box and restore it.
-PatP|||I did that, now I got my jobs back, but no dts packages ?|||Hmmm... Sorry, no clue. It has never failed me.
-PatP|||Then consider there is no chance to retrieve the DTS packages, consider this as a lesson and maintain regular backups for SYSTEM Databases too.
By any chance are the packages saved to a .VBscript files.|||To make a backup of all kinds of DTS packages or to transfer DTS packages between servers, please use the DTS Backup 2000 tool. This a very handy tool and it works very good; I use it myself ;) very often.
To get this tool please visit following URL: http://www.sqldts.com/default.aspx?202
I hope this helps to prevent new problems in the future.
Greetz,
DePrins :)|||Check the contents of sysdtspackages in the newly restored MSDB.|||this is antother reason that i always save these things as com files
you can place them in a centrally stored shared dir and back them up every night.
on a side note
you should create a job that backs up your master model and msdb dbs and schedule it for every night.
it's a whole lot better then running rebuildm.exe|||You can also do this by saving them as structured files. They're a little easier to handle and explain to the non-technical savvy people. :)|||"com file" = "com structured storage file"|||Thought you were referring to the visual basic file option. Oh well, who cares. Big thing is to make sure you save them.
Sunday, March 11, 2012
dts package failure when setup as job
opened on a client machine connected to a server. When I schedule it as a
job though Enterprise manager on the client machine connected to the server
the job fails. The package connects to an SQL database on the server as well
as an oracle database on another server. On job failure the event is written
to the windows event log on the server. The error message is Source SQL
Server agent,
status failed, the job failed.
I am thinking it may have to do with credentials, any ideas how to
troubleshoot this?
thanks.
Paul G
Software engineer.
Paul,
Yes, when you run it from Enterprise Manager, you are running under your
credentials. A scheduled job has different credentials.
When you schedule the DTS package from SQL Agent, it will run either as the
server account or as the account defined in xp_sqlagent_proxy_account for
your server. The SQL Server 2000 Books Online article on
xp_sqlagent_proxy_account has a fairly clear explanation.
Once you determine which credentials your job is using, then you can have
appropriate access granted to that account.
RLF
"Paul" <Paul@.discussions.microsoft.com> wrote in message
news:4E204B8C-1174-4713-A420-273E72F92178@.microsoft.com...
> HI I have a dts package (SQL 2000) that I can execute from Enterprise
> manager
> opened on a client machine connected to a server. When I schedule it as a
> job though Enterprise manager on the client machine connected to the
> server
> the job fails. The package connects to an SQL database on the server as
> well
> as an oracle database on another server. On job failure the event is
> written
> to the windows event log on the server. The error message is Source SQL
> Server agent,
> status failed, the job failed.
> I am thinking it may have to do with credentials, any ideas how to
> troubleshoot this?
> thanks.
> --
> Paul G
> Software engineer.
|||ok thanks for the information. Another problem is part of the package writes
to an Oracle database but the oracle client software is not installed on the
server.
Paul G
Software engineer.
"Russell Fields" wrote:
> Paul,
> Yes, when you run it from Enterprise Manager, you are running under your
> credentials. A scheduled job has different credentials.
> When you schedule the DTS package from SQL Agent, it will run either as the
> server account or as the account defined in xp_sqlagent_proxy_account for
> your server. The SQL Server 2000 Books Online article on
> xp_sqlagent_proxy_account has a fairly clear explanation.
> Once you determine which credentials your job is using, then you can have
> appropriate access granted to that account.
> RLF
>
> "Paul" <Paul@.discussions.microsoft.com> wrote in message
> news:4E204B8C-1174-4713-A420-273E72F92178@.microsoft.com...
>
>
|||Paul,
So that is the other part. When you run a DTS package from Enterprise
Manager in runs on the same machine that Enterprise Manager is running on.
So, if you are running EM on your desktop, that is where DTS runs as well.
Naturally if you have the Oracle client software on your desktop, it will
work for you.
If that is the case, then you will need to evaluate putting the Oracle
client software on the SQL Server. I don't have any experience with Oracle,
but plenty of people have successfully used DTS, Linked Servers, etc between
SQL Server and Oracle Server.
RLF
"Paul" <Paul@.discussions.microsoft.com> wrote in message
news:C5E14CA8-6327-4F64-854B-2C08274CE61D@.microsoft.com...[vbcol=seagreen]
> ok thanks for the information. Another problem is part of the package
> writes
> to an Oracle database but the oracle client software is not installed on
> the
> server.
> --
> Paul G
> Software engineer.
>
> "Russell Fields" wrote:
|||thanks for the additional information. I was wondering why it worked from my
client machine, but I do have the Oracle client software installed on it. I
had it on the server before but we ran into an issue with Appachi effecting
IIS so someone removed all of the Oracle software.
Paul G
Software engineer.
"Russell Fields" wrote:
> Paul,
> So that is the other part. When you run a DTS package from Enterprise
> Manager in runs on the same machine that Enterprise Manager is running on.
> So, if you are running EM on your desktop, that is where DTS runs as well.
> Naturally if you have the Oracle client software on your desktop, it will
> work for you.
> If that is the case, then you will need to evaluate putting the Oracle
> client software on the SQL Server. I don't have any experience with Oracle,
> but plenty of people have successfully used DTS, Linked Servers, etc between
> SQL Server and Oracle Server.
> RLF
> "Paul" <Paul@.discussions.microsoft.com> wrote in message
> news:C5E14CA8-6327-4F64-854B-2C08274CE61D@.microsoft.com...
>
>
dts package failure when setup as job
opened on a client machine connected to a server. When I schedule it as a
job though Enterprise manager on the client machine connected to the server
the job fails. The package connects to an SQL database on the server as well
as an oracle database on another server. On job failure the event is written
to the windows event log on the server. The error message is Source SQL
Server agent,
status failed, the job failed.
I am thinking it may have to do with credentials, any ideas how to
troubleshoot this?
thanks.
--
Paul G
Software engineer.Paul,
Yes, when you run it from Enterprise Manager, you are running under your
credentials. A scheduled job has different credentials.
When you schedule the DTS package from SQL Agent, it will run either as the
server account or as the account defined in xp_sqlagent_proxy_account for
your server. The SQL Server 2000 Books Online article on
xp_sqlagent_proxy_account has a fairly clear explanation.
Once you determine which credentials your job is using, then you can have
appropriate access granted to that account.
RLF
"Paul" <Paul@.discussions.microsoft.com> wrote in message
news:4E204B8C-1174-4713-A420-273E72F92178@.microsoft.com...
> HI I have a dts package (SQL 2000) that I can execute from Enterprise
> manager
> opened on a client machine connected to a server. When I schedule it as a
> job though Enterprise manager on the client machine connected to the
> server
> the job fails. The package connects to an SQL database on the server as
> well
> as an oracle database on another server. On job failure the event is
> written
> to the windows event log on the server. The error message is Source SQL
> Server agent,
> status failed, the job failed.
> I am thinking it may have to do with credentials, any ideas how to
> troubleshoot this?
> thanks.
> --
> Paul G
> Software engineer.|||ok thanks for the information. Another problem is part of the package writes
to an Oracle database but the oracle client software is not installed on the
server.
--
Paul G
Software engineer.
"Russell Fields" wrote:
> Paul,
> Yes, when you run it from Enterprise Manager, you are running under your
> credentials. A scheduled job has different credentials.
> When you schedule the DTS package from SQL Agent, it will run either as the
> server account or as the account defined in xp_sqlagent_proxy_account for
> your server. The SQL Server 2000 Books Online article on
> xp_sqlagent_proxy_account has a fairly clear explanation.
> Once you determine which credentials your job is using, then you can have
> appropriate access granted to that account.
> RLF
>
> "Paul" <Paul@.discussions.microsoft.com> wrote in message
> news:4E204B8C-1174-4713-A420-273E72F92178@.microsoft.com...
> > HI I have a dts package (SQL 2000) that I can execute from Enterprise
> > manager
> > opened on a client machine connected to a server. When I schedule it as a
> > job though Enterprise manager on the client machine connected to the
> > server
> > the job fails. The package connects to an SQL database on the server as
> > well
> > as an oracle database on another server. On job failure the event is
> > written
> > to the windows event log on the server. The error message is Source SQL
> > Server agent,
> > status failed, the job failed.
> > I am thinking it may have to do with credentials, any ideas how to
> > troubleshoot this?
> > thanks.
> > --
> > Paul G
> > Software engineer.
>
>|||Paul,
So that is the other part. When you run a DTS package from Enterprise
Manager in runs on the same machine that Enterprise Manager is running on.
So, if you are running EM on your desktop, that is where DTS runs as well.
Naturally if you have the Oracle client software on your desktop, it will
work for you.
If that is the case, then you will need to evaluate putting the Oracle
client software on the SQL Server. I don't have any experience with Oracle,
but plenty of people have successfully used DTS, Linked Servers, etc between
SQL Server and Oracle Server.
RLF
"Paul" <Paul@.discussions.microsoft.com> wrote in message
news:C5E14CA8-6327-4F64-854B-2C08274CE61D@.microsoft.com...
> ok thanks for the information. Another problem is part of the package
> writes
> to an Oracle database but the oracle client software is not installed on
> the
> server.
> --
> Paul G
> Software engineer.
>
> "Russell Fields" wrote:
>> Paul,
>> Yes, when you run it from Enterprise Manager, you are running under your
>> credentials. A scheduled job has different credentials.
>> When you schedule the DTS package from SQL Agent, it will run either as
>> the
>> server account or as the account defined in xp_sqlagent_proxy_account for
>> your server. The SQL Server 2000 Books Online article on
>> xp_sqlagent_proxy_account has a fairly clear explanation.
>> Once you determine which credentials your job is using, then you can have
>> appropriate access granted to that account.
>> RLF
>>
>> "Paul" <Paul@.discussions.microsoft.com> wrote in message
>> news:4E204B8C-1174-4713-A420-273E72F92178@.microsoft.com...
>> > HI I have a dts package (SQL 2000) that I can execute from Enterprise
>> > manager
>> > opened on a client machine connected to a server. When I schedule it
>> > as a
>> > job though Enterprise manager on the client machine connected to the
>> > server
>> > the job fails. The package connects to an SQL database on the server
>> > as
>> > well
>> > as an oracle database on another server. On job failure the event is
>> > written
>> > to the windows event log on the server. The error message is Source
>> > SQL
>> > Server agent,
>> > status failed, the job failed.
>> > I am thinking it may have to do with credentials, any ideas how to
>> > troubleshoot this?
>> > thanks.
>> > --
>> > Paul G
>> > Software engineer.
>>|||thanks for the additional information. I was wondering why it worked from my
client machine, but I do have the Oracle client software installed on it. I
had it on the server before but we ran into an issue with Appachi effecting
IIS so someone removed all of the Oracle software.
--
Paul G
Software engineer.
"Russell Fields" wrote:
> Paul,
> So that is the other part. When you run a DTS package from Enterprise
> Manager in runs on the same machine that Enterprise Manager is running on.
> So, if you are running EM on your desktop, that is where DTS runs as well.
> Naturally if you have the Oracle client software on your desktop, it will
> work for you.
> If that is the case, then you will need to evaluate putting the Oracle
> client software on the SQL Server. I don't have any experience with Oracle,
> but plenty of people have successfully used DTS, Linked Servers, etc between
> SQL Server and Oracle Server.
> RLF
> "Paul" <Paul@.discussions.microsoft.com> wrote in message
> news:C5E14CA8-6327-4F64-854B-2C08274CE61D@.microsoft.com...
> > ok thanks for the information. Another problem is part of the package
> > writes
> > to an Oracle database but the oracle client software is not installed on
> > the
> > server.
> > --
> > Paul G
> > Software engineer.
> >
> >
> > "Russell Fields" wrote:
> >
> >> Paul,
> >>
> >> Yes, when you run it from Enterprise Manager, you are running under your
> >> credentials. A scheduled job has different credentials.
> >>
> >> When you schedule the DTS package from SQL Agent, it will run either as
> >> the
> >> server account or as the account defined in xp_sqlagent_proxy_account for
> >> your server. The SQL Server 2000 Books Online article on
> >> xp_sqlagent_proxy_account has a fairly clear explanation.
> >>
> >> Once you determine which credentials your job is using, then you can have
> >> appropriate access granted to that account.
> >>
> >> RLF
> >>
> >>
> >> "Paul" <Paul@.discussions.microsoft.com> wrote in message
> >> news:4E204B8C-1174-4713-A420-273E72F92178@.microsoft.com...
> >> > HI I have a dts package (SQL 2000) that I can execute from Enterprise
> >> > manager
> >> > opened on a client machine connected to a server. When I schedule it
> >> > as a
> >> > job though Enterprise manager on the client machine connected to the
> >> > server
> >> > the job fails. The package connects to an SQL database on the server
> >> > as
> >> > well
> >> > as an oracle database on another server. On job failure the event is
> >> > written
> >> > to the windows event log on the server. The error message is Source
> >> > SQL
> >> > Server agent,
> >> > status failed, the job failed.
> >> > I am thinking it may have to do with credentials, any ideas how to
> >> > troubleshoot this?
> >> > thanks.
> >> > --
> >> > Paul G
> >> > Software engineer.
> >>
> >>
> >>
>
>
dts package failure when setup as job
r
opened on a client machine connected to a server. When I schedule it as a
job though Enterprise manager on the client machine connected to the server
the job fails. The package connects to an SQL database on the server as wel
l
as an oracle database on another server. On job failure the event is writte
n
to the windows event log on the server. The error message is Source SQL
Server agent,
status failed, the job failed.
I am thinking it may have to do with credentials, any ideas how to
troubleshoot this?
thanks.
--
Paul G
Software engineer.Paul,
Yes, when you run it from Enterprise Manager, you are running under your
credentials. A scheduled job has different credentials.
When you schedule the DTS package from SQL Agent, it will run either as the
server account or as the account defined in xp_sqlagent_proxy_account for
your server. The SQL Server 2000 Books Online article on
xp_sqlagent_proxy_account has a fairly clear explanation.
Once you determine which credentials your job is using, then you can have
appropriate access granted to that account.
RLF
"Paul" <Paul@.discussions.microsoft.com> wrote in message
news:4E204B8C-1174-4713-A420-273E72F92178@.microsoft.com...
> HI I have a dts package (SQL 2000) that I can execute from Enterprise
> manager
> opened on a client machine connected to a server. When I schedule it as a
> job though Enterprise manager on the client machine connected to the
> server
> the job fails. The package connects to an SQL database on the server as
> well
> as an oracle database on another server. On job failure the event is
> written
> to the windows event log on the server. The error message is Source SQL
> Server agent,
> status failed, the job failed.
> I am thinking it may have to do with credentials, any ideas how to
> troubleshoot this?
> thanks.
> --
> Paul G
> Software engineer.|||ok thanks for the information. Another problem is part of the package write
s
to an Oracle database but the oracle client software is not installed on the
server.
--
Paul G
Software engineer.
"Russell Fields" wrote:
> Paul,
> Yes, when you run it from Enterprise Manager, you are running under your
> credentials. A scheduled job has different credentials.
> When you schedule the DTS package from SQL Agent, it will run either as th
e
> server account or as the account defined in xp_sqlagent_proxy_account for
> your server. The SQL Server 2000 Books Online article on
> xp_sqlagent_proxy_account has a fairly clear explanation.
> Once you determine which credentials your job is using, then you can have
> appropriate access granted to that account.
> RLF
>
> "Paul" <Paul@.discussions.microsoft.com> wrote in message
> news:4E204B8C-1174-4713-A420-273E72F92178@.microsoft.com...
>
>|||Paul,
So that is the other part. When you run a DTS package from Enterprise
Manager in runs on the same machine that Enterprise Manager is running on.
So, if you are running EM on your desktop, that is where DTS runs as well.
Naturally if you have the Oracle client software on your desktop, it will
work for you.
If that is the case, then you will need to evaluate putting the Oracle
client software on the SQL Server. I don't have any experience with Oracle,
but plenty of people have successfully used DTS, Linked Servers, etc between
SQL Server and Oracle Server.
RLF
"Paul" <Paul@.discussions.microsoft.com> wrote in message
news:C5E14CA8-6327-4F64-854B-2C08274CE61D@.microsoft.com...[vbcol=seagreen]
> ok thanks for the information. Another problem is part of the package
> writes
> to an Oracle database but the oracle client software is not installed on
> the
> server.
> --
> Paul G
> Software engineer.
>
> "Russell Fields" wrote:
>|||thanks for the additional information. I was wondering why it worked from m
y
client machine, but I do have the Oracle client software installed on it. I
had it on the server before but we ran into an issue with Appachi effecting
IIS so someone removed all of the Oracle software.
--
Paul G
Software engineer.
"Russell Fields" wrote:
> Paul,
> So that is the other part. When you run a DTS package from Enterprise
> Manager in runs on the same machine that Enterprise Manager is running on.
> So, if you are running EM on your desktop, that is where DTS runs as well.
> Naturally if you have the Oracle client software on your desktop, it will
> work for you.
> If that is the case, then you will need to evaluate putting the Oracle
> client software on the SQL Server. I don't have any experience with Oracl
e,
> but plenty of people have successfully used DTS, Linked Servers, etc betwe
en
> SQL Server and Oracle Server.
> RLF
> "Paul" <Paul@.discussions.microsoft.com> wrote in message
> news:C5E14CA8-6327-4F64-854B-2C08274CE61D@.microsoft.com...
>
>
Friday, March 9, 2012
DTS package "Index Not Found Error"
The Scenario is we have a development machine that is actually a virtual machine and we have a test server. Virtual machine is XP professional based machine and Test Server is Windows Server 2003 based machine.
We have created a DTS package in Sql Server 2000 which copies data from 7 foxpro .dbf files to Sql Server 2000 based Database. This package when we test at our Development machine(Virtual Machine) works very fine, but when same DTS package is executed at Test Server it gives an Error, Below is the error which we found in DTS Logs.
Package failed because Step 'DTSStep_DTSDataPumpTask_1' failed.
**************************************************************************
Step Error Source: Microsoft JET Database Engine
Step Error Description:Index not found.
Step Error code: 80040E21
Step Error Help File:
Step Error Help Context ID:5003015
***********************************************************************
All the tables are located at the same place. and in both the machine source path remains the same for DTS package.
One observation is that some time on test server DTS package copies data from 2 or 3 tables but fails for remaining and sometime it may fail for all.
Checks have been made to ensure that there is no access violation issue.
Looking forward for a quick Help
Thanks
Pranjal Sharma
One of the reason:
A Data Transformation Services (DTS) package that was created on a Microsoft Windows 2000 computer may not run when scheduled on a server without Microsoft Data Access Components (MDAC) version 2.5 installed. The same problem occurs if you run the package on the server with DTSRun
|||But we have created the DTS package in Windows XP professional and not on Windows 2000 machine. One more interesting thing is that among 7 tasks few execute and few fail. I hope this would help you in thinking further about the query.
Thanks
Pranjal Sharma
|||You might need to check the MDAC version of server and on the machine where these DTS packages were created, also look at the DTS log for more information on this failure.|||I tried checking the Versions. on the development machine MDAC version is 2.81 and on Test server it is 2.82. The log gives error which i provided in my first post.
But one thing i observed is that, If we give a select query which contains a Where clause, Then DTS package gives error and if we use select * from <tablename> then DTS is executed properly.
Wednesday, March 7, 2012
DTS Package
I created a SQL Server DTS package when connecting to the SQL server on my
machine. We have a batch file created which was scheduled to run every Tue.
night on the server where SQL server really sits. In the batch file, we use
dtsrun to call this package. It has been running well. I shut my computer
down this Tue. after work. I got an error message from running the package.
Step Error Source: Microsoft JET Database Engine
Step Error Description:'I:\68\data_from_county' is not a valid path. Make
sure that the path name is spelled correctly and that you are connected to
the server on which the file resides.
Step Error code: 80004005
Step Error Help File:
Step Error Help Context ID:5003044
Should the package be run on the server? It should have nothing to do with
my computer, right? I got very confused. Any help will be greatly
appreciated.
CindyDTS is a client side software. When invoked from Enterprise Manager on a
client, the package actually runs on the client PC. When invoked from a job,
it runs on the server side.
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
"Cindy" <cindyhe@.bonestroo.com> wrote in message
news:uIkoZNshEHA.3988@.tk2msftngp13.phx.gbl...
Hi All,
I created a SQL Server DTS package when connecting to the SQL server on my
machine. We have a batch file created which was scheduled to run every Tue.
night on the server where SQL server really sits. In the batch file, we use
dtsrun to call this package. It has been running well. I shut my computer
down this Tue. after work. I got an error message from running the package.
Step Error Source: Microsoft JET Database Engine
Step Error Description:'I:\68\data_from_county' is not a valid path. Make
sure that the path name is spelled correctly and that you are connected to
the server on which the file resides.
Step Error code: 80004005
Step Error Help File:
Step Error Help Context ID:5003044
Should the package be run on the server? It should have nothing to do with
my computer, right? I got very confused. Any help will be greatly
appreciated.
Cindy|||Thanks for the quick response.
We have a batch file which calls to run this package on the server. Should
it run on the server side as you said? If so, it should have nothing with my
computer, right?
Cindy
"Narayana Vyas Kondreddi" <answer_me@.hotmail.com> wrote in message
news:uvn14PshEHA.632@.TK2MSFTNGP12.phx.gbl...
> DTS is a client side software. When invoked from Enterprise Manager on a
> client, the package actually runs on the client PC. When invoked from a
job,
> it runs on the server side.
> --
> HTH,
> Vyas, MVP (SQL Server)
> http://vyaskn.tripod.com/
>
> "Cindy" <cindyhe@.bonestroo.com> wrote in message
> news:uIkoZNshEHA.3988@.tk2msftngp13.phx.gbl...
> Hi All,
> I created a SQL Server DTS package when connecting to the SQL server on my
> machine. We have a batch file created which was scheduled to run every
Tue.
> night on the server where SQL server really sits. In the batch file, we
use
> dtsrun to call this package. It has been running well. I shut my computer
> down this Tue. after work. I got an error message from running the
package.
> Step Error Source: Microsoft JET Database Engine
> Step Error Description:'I:\68\data_from_county' is not a valid path. Make
> sure that the path name is spelled correctly and that you are connected to
> the server on which the file resides.
> Step Error code: 80004005
> Step Error Help File:
> Step Error Help Context ID:5003044
> Should the package be run on the server? It should have nothing to do with
> my computer, right? I got very confused. Any help will be greatly
> appreciated.
> Cindy
>
>
>|||If u call it from a batch file, and the batch file is on your machine, then
the package will run on your machine, not server.
To make sure the package runs on the server, schedule it using an SQL Agent
job.
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
"Cindy" <cindyhe@.bonestroo.com> wrote in message
news:O2O12YshEHA.1276@.TK2MSFTNGP09.phx.gbl...
Thanks for the quick response.
We have a batch file which calls to run this package on the server. Should
it run on the server side as you said? If so, it should have nothing with my
computer, right?
Cindy
"Narayana Vyas Kondreddi" <answer_me@.hotmail.com> wrote in message
news:uvn14PshEHA.632@.TK2MSFTNGP12.phx.gbl...
> DTS is a client side software. When invoked from Enterprise Manager on a
> client, the package actually runs on the client PC. When invoked from a
job,
> it runs on the server side.
> --
> HTH,
> Vyas, MVP (SQL Server)
> http://vyaskn.tripod.com/
>
> "Cindy" <cindyhe@.bonestroo.com> wrote in message
> news:uIkoZNshEHA.3988@.tk2msftngp13.phx.gbl...
> Hi All,
> I created a SQL Server DTS package when connecting to the SQL server on my
> machine. We have a batch file created which was scheduled to run every
Tue.
> night on the server where SQL server really sits. In the batch file, we
use
> dtsrun to call this package. It has been running well. I shut my computer
> down this Tue. after work. I got an error message from running the
package.
> Step Error Source: Microsoft JET Database Engine
> Step Error Description:'I:\68\data_from_county' is not a valid path. Make
> sure that the path name is spelled correctly and that you are connected to
> the server on which the file resides.
> Step Error code: 80004005
> Step Error Help File:
> Step Error Help Context ID:5003044
> Should the package be run on the server? It should have nothing to do with
> my computer, right? I got very confused. Any help will be greatly
> appreciated.
> Cindy
>
>
>|||> To make sure the package runs on the server, schedule it using an SQL
Agent
> job.
Or, a windows scheduled task *on the server* calling a batch file *on the
server*...
The advantage this /could/ have is that the scheduled task could be run as a
different user than the SQL Agent service account...
A|||We have a windows scheduled task on the server calling a batch file on the
server. This is exactly what you mentioned here.
Will who owns this package make any difference or is it an issue that we
should take into account? Should I change the package owner to dbo?
Cindy
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:eGP93gshEHA.4064@.TK2MSFTNGP12.phx.gbl...
> > To make sure the package runs on the server, schedule it using an SQL
> Agent
> > job.
> Or, a windows scheduled task *on the server* calling a batch file *on the
> server*...
> The advantage this /could/ have is that the scheduled task could be run as
a
> different user than the SQL Agent service account...
> A
>