Hi,
Apparently Visual Studio 2005 is normally needed to debug
SQL Server 2005 problems. For example stored procedures
written in managed code. What is the recommended way to
do debugging on a production server that doesn't have VS
on it? Remote debugging from another machine on the
same LAN? What if that isn't possible? ADPlus, dump
files and the SOS debugger extension?
Thanks,
Alan Cobb
Hi
Usually you would not want to do this on a live system, but a copy, as
potentially you could cause havoc if you do this. Any code change should go
through a proper review/test/release process.
John
"Alan Cobb" wrote:
> Hi,
> Apparently Visual Studio 2005 is normally needed to debug
> SQL Server 2005 problems. For example stored procedures
> written in managed code. What is the recommended way to
> do debugging on a production server that doesn't have VS
> on it? Remote debugging from another machine on the
> same LAN? What if that isn't possible? ADPlus, dump
> files and the SOS debugger extension?
> Thanks,
> Alan Cobb
>
|||Hi John,
Let's say we've exhausted all the "non-live" approaches
and there is some bug (not just the stored procedure example)
that only happens on a particular live system.
Maybe "production debugging" just doesn't come up that much
in the SQL Server world, but in the ASP.NET world people do
have to occasionally debug problems on live ASP.NET servers.
Partly for security reasons people often don't want to install
Visual Studio's debugger on a production ASP.NET server, so
they capture dump files with ADPlus. Then they analyze the
dump files in a debugger somewhere else. But maybe that's
not as common in the SQL Server world?
Thanks,
Alan Cobb
On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
<jbellnewsposts@.hotmail.com> wrote:
[vbcol=seagreen]
>Hi
>Usually you would not want to do this on a live system, but a copy, as
>potentially you could cause havoc if you do this. Any code change should go
>through a proper review/test/release process.
>John
>"Alan Cobb" wrote:
|||Hi Alan
With backend systems control and auditability can be a mandatory requirement
depending on your circumstances. Also if a business' wellbeing it dependent
on such systems it would be outside of the remit for a developer to decide
what should/should not be done on these servers. This is obviously dependent
on the company and may well be different for yours.
If you have the web logs maybe you can recreate the problem by replaying
them using ACT. This may give you the opportunity to debug the application in
a controlled environment, alternatively if you can validate that you will not
get the issue one a set of hardware you may want to consider
changing/rebuilding the system.
John
"Alan Cobb" wrote:
> Hi John,
> Let's say we've exhausted all the "non-live" approaches
> and there is some bug (not just the stored procedure example)
> that only happens on a particular live system.
> Maybe "production debugging" just doesn't come up that much
> in the SQL Server world, but in the ASP.NET world people do
> have to occasionally debug problems on live ASP.NET servers.
> Partly for security reasons people often don't want to install
> Visual Studio's debugger on a production ASP.NET server, so
> they capture dump files with ADPlus. Then they analyze the
> dump files in a debugger somewhere else. But maybe that's
> not as common in the SQL Server world?
> Thanks,
> Alan Cobb
> On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
> <jbellnewsposts@.hotmail.com> wrote:
>
>
Showing posts with label studio. Show all posts
Showing posts with label studio. Show all posts
Monday, March 26, 2012
Production debugging of SQL Server 2005 without VS 2005?
Hi,
Apparently Visual Studio 2005 is normally needed to debug
SQL Server 2005 problems. For example stored procedures
written in managed code. What is the recommended way to
do debugging on a production server that doesn't have VS
on it? Remote debugging from another machine on the
same LAN? What if that isn't possible? ADPlus, dump
files and the SOS debugger extension?
Thanks,
Alan CobbHi
Usually you would not want to do this on a live system, but a copy, as
potentially you could cause havoc if you do this. Any code change should go
through a proper review/test/release process.
John
"Alan Cobb" wrote:
> Hi,
> Apparently Visual Studio 2005 is normally needed to debug
> SQL Server 2005 problems. For example stored procedures
> written in managed code. What is the recommended way to
> do debugging on a production server that doesn't have VS
> on it? Remote debugging from another machine on the
> same LAN? What if that isn't possible? ADPlus, dump
> files and the SOS debugger extension?
> Thanks,
> Alan Cobb
>|||Hi John,
Let's say we've exhausted all the "non-live" approaches
and there is some bug (not just the stored procedure example)
that only happens on a particular live system.
Maybe "production debugging" just doesn't come up that much
in the SQL Server world, but in the ASP.NET world people do
have to occasionally debug problems on live ASP.NET servers.
Partly for security reasons people often don't want to install
Visual Studio's debugger on a production ASP.NET server, so
they capture dump files with ADPlus. Then they analyze the
dump files in a debugger somewhere else. But maybe that's
not as common in the SQL Server world?
Thanks,
Alan Cobb
On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
<jbellnewsposts@.hotmail.com> wrote:
>Hi
>Usually you would not want to do this on a live system, but a copy, as
>potentially you could cause havoc if you do this. Any code change should go
>through a proper review/test/release process.
>John
>"Alan Cobb" wrote:
>> Hi,
>> Apparently Visual Studio 2005 is normally needed to debug
>> SQL Server 2005 problems. For example stored procedures
>> written in managed code. What is the recommended way to
>> do debugging on a production server that doesn't have VS
>> on it? Remote debugging from another machine on the
>> same LAN? What if that isn't possible? ADPlus, dump
>> files and the SOS debugger extension?
>> Thanks,
>> Alan Cobb|||Hi Alan
With backend systems control and auditability can be a mandatory requirement
depending on your circumstances. Also if a business' wellbeing it dependent
on such systems it would be outside of the remit for a developer to decide
what should/should not be done on these servers. This is obviously dependent
on the company and may well be different for yours.
If you have the web logs maybe you can recreate the problem by replaying
them using ACT. This may give you the opportunity to debug the application in
a controlled environment, alternatively if you can validate that you will not
get the issue one a set of hardware you may want to consider
changing/rebuilding the system.
John
"Alan Cobb" wrote:
> Hi John,
> Let's say we've exhausted all the "non-live" approaches
> and there is some bug (not just the stored procedure example)
> that only happens on a particular live system.
> Maybe "production debugging" just doesn't come up that much
> in the SQL Server world, but in the ASP.NET world people do
> have to occasionally debug problems on live ASP.NET servers.
> Partly for security reasons people often don't want to install
> Visual Studio's debugger on a production ASP.NET server, so
> they capture dump files with ADPlus. Then they analyze the
> dump files in a debugger somewhere else. But maybe that's
> not as common in the SQL Server world?
> Thanks,
> Alan Cobb
> On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
> <jbellnewsposts@.hotmail.com> wrote:
> >Hi
> >
> >Usually you would not want to do this on a live system, but a copy, as
> >potentially you could cause havoc if you do this. Any code change should go
> >through a proper review/test/release process.
> >
> >John
> >
> >"Alan Cobb" wrote:
> >
> >> Hi,
> >>
> >> Apparently Visual Studio 2005 is normally needed to debug
> >> SQL Server 2005 problems. For example stored procedures
> >> written in managed code. What is the recommended way to
> >> do debugging on a production server that doesn't have VS
> >> on it? Remote debugging from another machine on the
> >> same LAN? What if that isn't possible? ADPlus, dump
> >> files and the SOS debugger extension?
> >>
> >> Thanks,
> >> Alan Cobb
> >>
>sql
Apparently Visual Studio 2005 is normally needed to debug
SQL Server 2005 problems. For example stored procedures
written in managed code. What is the recommended way to
do debugging on a production server that doesn't have VS
on it? Remote debugging from another machine on the
same LAN? What if that isn't possible? ADPlus, dump
files and the SOS debugger extension?
Thanks,
Alan CobbHi
Usually you would not want to do this on a live system, but a copy, as
potentially you could cause havoc if you do this. Any code change should go
through a proper review/test/release process.
John
"Alan Cobb" wrote:
> Hi,
> Apparently Visual Studio 2005 is normally needed to debug
> SQL Server 2005 problems. For example stored procedures
> written in managed code. What is the recommended way to
> do debugging on a production server that doesn't have VS
> on it? Remote debugging from another machine on the
> same LAN? What if that isn't possible? ADPlus, dump
> files and the SOS debugger extension?
> Thanks,
> Alan Cobb
>|||Hi John,
Let's say we've exhausted all the "non-live" approaches
and there is some bug (not just the stored procedure example)
that only happens on a particular live system.
Maybe "production debugging" just doesn't come up that much
in the SQL Server world, but in the ASP.NET world people do
have to occasionally debug problems on live ASP.NET servers.
Partly for security reasons people often don't want to install
Visual Studio's debugger on a production ASP.NET server, so
they capture dump files with ADPlus. Then they analyze the
dump files in a debugger somewhere else. But maybe that's
not as common in the SQL Server world?
Thanks,
Alan Cobb
On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
<jbellnewsposts@.hotmail.com> wrote:
>Hi
>Usually you would not want to do this on a live system, but a copy, as
>potentially you could cause havoc if you do this. Any code change should go
>through a proper review/test/release process.
>John
>"Alan Cobb" wrote:
>> Hi,
>> Apparently Visual Studio 2005 is normally needed to debug
>> SQL Server 2005 problems. For example stored procedures
>> written in managed code. What is the recommended way to
>> do debugging on a production server that doesn't have VS
>> on it? Remote debugging from another machine on the
>> same LAN? What if that isn't possible? ADPlus, dump
>> files and the SOS debugger extension?
>> Thanks,
>> Alan Cobb|||Hi Alan
With backend systems control and auditability can be a mandatory requirement
depending on your circumstances. Also if a business' wellbeing it dependent
on such systems it would be outside of the remit for a developer to decide
what should/should not be done on these servers. This is obviously dependent
on the company and may well be different for yours.
If you have the web logs maybe you can recreate the problem by replaying
them using ACT. This may give you the opportunity to debug the application in
a controlled environment, alternatively if you can validate that you will not
get the issue one a set of hardware you may want to consider
changing/rebuilding the system.
John
"Alan Cobb" wrote:
> Hi John,
> Let's say we've exhausted all the "non-live" approaches
> and there is some bug (not just the stored procedure example)
> that only happens on a particular live system.
> Maybe "production debugging" just doesn't come up that much
> in the SQL Server world, but in the ASP.NET world people do
> have to occasionally debug problems on live ASP.NET servers.
> Partly for security reasons people often don't want to install
> Visual Studio's debugger on a production ASP.NET server, so
> they capture dump files with ADPlus. Then they analyze the
> dump files in a debugger somewhere else. But maybe that's
> not as common in the SQL Server world?
> Thanks,
> Alan Cobb
> On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
> <jbellnewsposts@.hotmail.com> wrote:
> >Hi
> >
> >Usually you would not want to do this on a live system, but a copy, as
> >potentially you could cause havoc if you do this. Any code change should go
> >through a proper review/test/release process.
> >
> >John
> >
> >"Alan Cobb" wrote:
> >
> >> Hi,
> >>
> >> Apparently Visual Studio 2005 is normally needed to debug
> >> SQL Server 2005 problems. For example stored procedures
> >> written in managed code. What is the recommended way to
> >> do debugging on a production server that doesn't have VS
> >> on it? Remote debugging from another machine on the
> >> same LAN? What if that isn't possible? ADPlus, dump
> >> files and the SOS debugger extension?
> >>
> >> Thanks,
> >> Alan Cobb
> >>
>sql
Production debugging of SQL Server 2005 without VS 2005?
Hi,
Apparently Visual Studio 2005 is normally needed to debug
SQL Server 2005 problems. For example stored procedures
written in managed code. What is the recommended way to
do debugging on a production server that doesn't have VS
on it? Remote debugging from another machine on the
same LAN? What if that isn't possible? ADPlus, dump
files and the SOS debugger extension?
Thanks,
Alan CobbHi
Usually you would not want to do this on a live system, but a copy, as
potentially you could cause havoc if you do this. Any code change should go
through a proper review/test/release process.
John
"Alan Cobb" wrote:
> Hi,
> Apparently Visual Studio 2005 is normally needed to debug
> SQL Server 2005 problems. For example stored procedures
> written in managed code. What is the recommended way to
> do debugging on a production server that doesn't have VS
> on it? Remote debugging from another machine on the
> same LAN? What if that isn't possible? ADPlus, dump
> files and the SOS debugger extension?
> Thanks,
> Alan Cobb
>|||Hi John,
Let's say we've exhausted all the "non-live" approaches
and there is some bug (not just the stored procedure example)
that only happens on a particular live system.
Maybe "production debugging" just doesn't come up that much
in the SQL Server world, but in the ASP.NET world people do
have to occasionally debug problems on live ASP.NET servers.
Partly for security reasons people often don't want to install
Visual Studio's debugger on a production ASP.NET server, so
they capture dump files with ADPlus. Then they analyze the
dump files in a debugger somewhere else. But maybe that's
not as common in the SQL Server world?
Thanks,
Alan Cobb
On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
<jbellnewsposts@.hotmail.com> wrote:
[vbcol=seagreen]
>Hi
>Usually you would not want to do this on a live system, but a copy, as
>potentially you could cause havoc if you do this. Any code change should go
>through a proper review/test/release process.
>John
>"Alan Cobb" wrote:
>|||Hi Alan
With backend systems control and auditability can be a mandatory requirement
depending on your circumstances. Also if a business' wellbeing it dependent
on such systems it would be outside of the remit for a developer to decide
what should/should not be done on these servers. This is obviously dependent
on the company and may well be different for yours.
If you have the web logs maybe you can recreate the problem by replaying
them using ACT. This may give you the opportunity to debug the application i
n
a controlled environment, alternatively if you can validate that you will no
t
get the issue one a set of hardware you may want to consider
changing/rebuilding the system.
John
"Alan Cobb" wrote:
> Hi John,
> Let's say we've exhausted all the "non-live" approaches
> and there is some bug (not just the stored procedure example)
> that only happens on a particular live system.
> Maybe "production debugging" just doesn't come up that much
> in the SQL Server world, but in the ASP.NET world people do
> have to occasionally debug problems on live ASP.NET servers.
> Partly for security reasons people often don't want to install
> Visual Studio's debugger on a production ASP.NET server, so
> they capture dump files with ADPlus. Then they analyze the
> dump files in a debugger somewhere else. But maybe that's
> not as common in the SQL Server world?
> Thanks,
> Alan Cobb
> On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
> <jbellnewsposts@.hotmail.com> wrote:
>
>
Apparently Visual Studio 2005 is normally needed to debug
SQL Server 2005 problems. For example stored procedures
written in managed code. What is the recommended way to
do debugging on a production server that doesn't have VS
on it? Remote debugging from another machine on the
same LAN? What if that isn't possible? ADPlus, dump
files and the SOS debugger extension?
Thanks,
Alan CobbHi
Usually you would not want to do this on a live system, but a copy, as
potentially you could cause havoc if you do this. Any code change should go
through a proper review/test/release process.
John
"Alan Cobb" wrote:
> Hi,
> Apparently Visual Studio 2005 is normally needed to debug
> SQL Server 2005 problems. For example stored procedures
> written in managed code. What is the recommended way to
> do debugging on a production server that doesn't have VS
> on it? Remote debugging from another machine on the
> same LAN? What if that isn't possible? ADPlus, dump
> files and the SOS debugger extension?
> Thanks,
> Alan Cobb
>|||Hi John,
Let's say we've exhausted all the "non-live" approaches
and there is some bug (not just the stored procedure example)
that only happens on a particular live system.
Maybe "production debugging" just doesn't come up that much
in the SQL Server world, but in the ASP.NET world people do
have to occasionally debug problems on live ASP.NET servers.
Partly for security reasons people often don't want to install
Visual Studio's debugger on a production ASP.NET server, so
they capture dump files with ADPlus. Then they analyze the
dump files in a debugger somewhere else. But maybe that's
not as common in the SQL Server world?
Thanks,
Alan Cobb
On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
<jbellnewsposts@.hotmail.com> wrote:
[vbcol=seagreen]
>Hi
>Usually you would not want to do this on a live system, but a copy, as
>potentially you could cause havoc if you do this. Any code change should go
>through a proper review/test/release process.
>John
>"Alan Cobb" wrote:
>|||Hi Alan
With backend systems control and auditability can be a mandatory requirement
depending on your circumstances. Also if a business' wellbeing it dependent
on such systems it would be outside of the remit for a developer to decide
what should/should not be done on these servers. This is obviously dependent
on the company and may well be different for yours.
If you have the web logs maybe you can recreate the problem by replaying
them using ACT. This may give you the opportunity to debug the application i
n
a controlled environment, alternatively if you can validate that you will no
t
get the issue one a set of hardware you may want to consider
changing/rebuilding the system.
John
"Alan Cobb" wrote:
> Hi John,
> Let's say we've exhausted all the "non-live" approaches
> and there is some bug (not just the stored procedure example)
> that only happens on a particular live system.
> Maybe "production debugging" just doesn't come up that much
> in the SQL Server world, but in the ASP.NET world people do
> have to occasionally debug problems on live ASP.NET servers.
> Partly for security reasons people often don't want to install
> Visual Studio's debugger on a production ASP.NET server, so
> they capture dump files with ADPlus. Then they analyze the
> dump files in a debugger somewhere else. But maybe that's
> not as common in the SQL Server world?
> Thanks,
> Alan Cobb
> On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
> <jbellnewsposts@.hotmail.com> wrote:
>
>
Product level is insufficient error
Configuration: Windows XP Pro with SQL 2005 Workgroup Sp2 Features/Integration Services Enhancements EE (32-bit) DE (32-bit) EE (64-bit) DE (64-bit) SE (32-bit) WG (32-bit) SSE (32-bit) SSEA (32-bit) SE (64-bit)
Hi, we have a package that runs fine in BI Studio but fails with the following error when executing it using DTExec.
Code: 0xC00470FE
Source: Data Flow Task DTS.Pipeline
Description: SSIS Error Code DTS_E_PRODUCTLEVELTOLOW. The product level is insufficient for component "Derived Column" (10660).
The package imports a CSV into a table mapping some columns. The MSDN article at http://msdn2.microsoft.com/en-us/library/ms143761.aspx describes features supported by different versions.
The article says OLE DB source/destination adapters are supported in WG edition but a couple of lines later seems to imply that all source/destination adapters are not supported in WG.
Could you clarify whether stuff like import of a csv into a table with some column mappings should work in WG edition? Also if we have a legacy SQL 2K package doing the same thing, will that work in WG edition? Thx.
SQL Server Import and Export Wizard and supporting connections, source and destination adapters, and tasks
Yes
Yes
Yes
No
Yes
Execute SQL Task
Yes
Yes
Yes
No
Yes
OLE DB Source and Destination Adapters
Yes
Yes
Yes
No
Yes
SSIS command prompt tools
Yes
Yes
Yes
No
Yes
SSIS Package Designer
Yes
Yes
Yes
No
Yes
Legacy support for DTS packages
Yes
Yes
Yes
Yes
Yes
SSIS Service
Yes
Yes
No
No
Yes
All other source and destination adapters, tasks, and transformations, except for those listed below
Yes
Yes
No
No
Yes
You might want to be sure that you have actually installed the full SSIS client.|||
As Phil wrote, most likely you've only Workstation components installed and need to install full SSIS.
See Books Online and my blog for details:
http://msdn2.microsoft.com/en-US/library/aa337371.aspx
http://blogs.msdn.com/michen/archive/2006/11/11/ssis-product-level-is-insufficient.aspx
Subscribe to:
Posts (Atom)