Our database(s) are all over the place - no documentation - lot's of
rubbish and unused stuff.
I'm managing a project focusing on data quality that covers code
changes, alterations to DTS packages, schema changes etc etc.
What I'd like to do is see where the bit I want to change is being
used.
that might mean what stored procs use a field and what sprocs use that
sproc.
maybe it's which dts packages use a sproc (and again up the
hieararchy)
The list is a long one but basically I need to know what the effects
are of changes.
Is there a tool out there that lets me navigate a database to that
level of detail - I understand something along the same lines is
available for MS Access but I can't find it for SQL Server.
ThanksRed-Gate has a pretty cool tool called SQL Dependency Tracker that you
should check out:
http://www.red-gate.com/products/SQ...acker/index.htm
There's also a stored proc in SQL Server called sp_depends which queries
an internal view called sysdepends. You can also check that out if you
want to spend $0 on new software. A warning: sysdepends is not that
reliable, or at least it hasn't been for me in the past. I don't really
know if SQL Server 2005 makes it more useful than it was in 2000. Does
anyone on the group know if there have been any significant enhancements
to sysdepends in 2005?
oliver wrote:
> Our database(s) are all over the place - no documentation - lot's of
> rubbish and unused stuff.
> I'm managing a project focusing on data quality that covers code
> changes, alterations to DTS packages, schema changes etc etc.
> What I'd like to do is see where the bit I want to change is being
> used.
> that might mean what stored procs use a field and what sprocs use that
> sproc.
> maybe it's which dts packages use a sproc (and again up the
> hieararchy)
> The list is a long one but basically I need to know what the effects
> are of changes.
> Is there a tool out there that lets me navigate a database to that
> level of detail - I understand something along the same lines is
> available for MS Access but I can't find it for SQL Server.
> Thanks
>|||On 26 Feb, 22:54, David Markle <new...@.markleconsulting.c0m> wrote:
> Red-Gate has a pretty cool tool called SQL Dependency Tracker that you
> should check out:
> http://www.red-gate.com/products/SQ...acker/index.htm
> There's also a stored proc in SQL Server called sp_depends which queries
> an internal view called sysdepends. You can also check that out if you
> want to spend $0 on new software. A warning: sysdepends is not that
> reliable, or at least it hasn't been for me in the past. I don't really
> know if SQL Server 2005 makes it more useful than it was in 2000. Does
> anyone on the group know if there have been any significant enhancements
> to sysdepends in 2005?
>
> oliver wrote:
>
>
>
> - Show quoted text -
it's not really fully featured enough I don' think - money's not
really too much of an issue - surely there something a bit more meaty?
Showing posts with label stuff. Show all posts
Showing posts with label stuff. Show all posts
Monday, March 19, 2012
maintaining/altering database
Our database(s) are all over the place - no documentation - lot's of
rubbish and unused stuff.
I'm managing a project focusing on data quality that covers code
changes, alterations to DTS packages, schema changes etc etc.
What I'd like to do is see where the bit I want to change is being
used.
that might mean what stored procs use a field and what sprocs use that
sproc.
maybe it's which dts packages use a sproc (and again up the
hieararchy)
The list is a long one but basically I need to know what the effects
are of changes.
Is there a tool out there that lets me navigate a database to that
level of detail - I understand something along the same lines is
available for MS Access but I can't find it for SQL Server.
Thanks
Red-Gate has a pretty cool tool called SQL Dependency Tracker that you
should check out:
http://www.red-gate.com/products/SQL_Dependency_Tracker/index.htm
There's also a stored proc in SQL Server called sp_depends which queries
an internal view called sysdepends. You can also check that out if you
want to spend $0 on new software. A warning: sysdepends is not that
reliable, or at least it hasn't been for me in the past. I don't really
know if SQL Server 2005 makes it more useful than it was in 2000. Does
anyone on the group know if there have been any significant enhancements
to sysdepends in 2005?
oliver wrote:
> Our database(s) are all over the place - no documentation - lot's of
> rubbish and unused stuff.
> I'm managing a project focusing on data quality that covers code
> changes, alterations to DTS packages, schema changes etc etc.
> What I'd like to do is see where the bit I want to change is being
> used.
> that might mean what stored procs use a field and what sprocs use that
> sproc.
> maybe it's which dts packages use a sproc (and again up the
> hieararchy)
> The list is a long one but basically I need to know what the effects
> are of changes.
> Is there a tool out there that lets me navigate a database to that
> level of detail - I understand something along the same lines is
> available for MS Access but I can't find it for SQL Server.
> Thanks
>
|||On 26 Feb, 22:54, David Markle <new...@.markleconsulting.c0m> wrote:
> Red-Gate has a pretty cool tool called SQL Dependency Tracker that you
> should check out:
> http://www.red-gate.com/products/SQL_Dependency_Tracker/index.htm
> There's also a stored proc in SQL Server called sp_depends which queries
> an internal view called sysdepends. You can also check that out if you
> want to spend $0 on new software. A warning: sysdepends is not that
> reliable, or at least it hasn't been for me in the past. I don't really
> know if SQL Server 2005 makes it more useful than it was in 2000. Does
> anyone on the group know if there have been any significant enhancements
> to sysdepends in 2005?
>
> oliver wrote:
>
>
> - Show quoted text -
it's not really fully featured enough I don' think - money's not
really too much of an issue - surely there something a bit more meaty?
rubbish and unused stuff.
I'm managing a project focusing on data quality that covers code
changes, alterations to DTS packages, schema changes etc etc.
What I'd like to do is see where the bit I want to change is being
used.
that might mean what stored procs use a field and what sprocs use that
sproc.
maybe it's which dts packages use a sproc (and again up the
hieararchy)
The list is a long one but basically I need to know what the effects
are of changes.
Is there a tool out there that lets me navigate a database to that
level of detail - I understand something along the same lines is
available for MS Access but I can't find it for SQL Server.
Thanks
Red-Gate has a pretty cool tool called SQL Dependency Tracker that you
should check out:
http://www.red-gate.com/products/SQL_Dependency_Tracker/index.htm
There's also a stored proc in SQL Server called sp_depends which queries
an internal view called sysdepends. You can also check that out if you
want to spend $0 on new software. A warning: sysdepends is not that
reliable, or at least it hasn't been for me in the past. I don't really
know if SQL Server 2005 makes it more useful than it was in 2000. Does
anyone on the group know if there have been any significant enhancements
to sysdepends in 2005?
oliver wrote:
> Our database(s) are all over the place - no documentation - lot's of
> rubbish and unused stuff.
> I'm managing a project focusing on data quality that covers code
> changes, alterations to DTS packages, schema changes etc etc.
> What I'd like to do is see where the bit I want to change is being
> used.
> that might mean what stored procs use a field and what sprocs use that
> sproc.
> maybe it's which dts packages use a sproc (and again up the
> hieararchy)
> The list is a long one but basically I need to know what the effects
> are of changes.
> Is there a tool out there that lets me navigate a database to that
> level of detail - I understand something along the same lines is
> available for MS Access but I can't find it for SQL Server.
> Thanks
>
|||On 26 Feb, 22:54, David Markle <new...@.markleconsulting.c0m> wrote:
> Red-Gate has a pretty cool tool called SQL Dependency Tracker that you
> should check out:
> http://www.red-gate.com/products/SQL_Dependency_Tracker/index.htm
> There's also a stored proc in SQL Server called sp_depends which queries
> an internal view called sysdepends. You can also check that out if you
> want to spend $0 on new software. A warning: sysdepends is not that
> reliable, or at least it hasn't been for me in the past. I don't really
> know if SQL Server 2005 makes it more useful than it was in 2000. Does
> anyone on the group know if there have been any significant enhancements
> to sysdepends in 2005?
>
> oliver wrote:
>
>
> - Show quoted text -
it's not really fully featured enough I don' think - money's not
really too much of an issue - surely there something a bit more meaty?
maintaining/altering database
Our database(s) are all over the place - no documentation - lot's of
rubbish and unused stuff.
I'm managing a project focusing on data quality that covers code
changes, alterations to DTS packages, schema changes etc etc.
What I'd like to do is see where the bit I want to change is being
used.
that might mean what stored procs use a field and what sprocs use that
sproc.
maybe it's which dts packages use a sproc (and again up the
hieararchy)
The list is a long one but basically I need to know what the effects
are of changes.
Is there a tool out there that lets me navigate a database to that
level of detail - I understand something along the same lines is
available for MS Access but I can't find it for SQL Server.
ThanksRed-Gate has a pretty cool tool called SQL Dependency Tracker that you
should check out:
http://www.red-gate.com/products/SQL_Dependency_Tracker/index.htm
There's also a stored proc in SQL Server called sp_depends which queries
an internal view called sysdepends. You can also check that out if you
want to spend $0 on new software. A warning: sysdepends is not that
reliable, or at least it hasn't been for me in the past. I don't really
know if SQL Server 2005 makes it more useful than it was in 2000. Does
anyone on the group know if there have been any significant enhancements
to sysdepends in 2005?
oliver wrote:
> Our database(s) are all over the place - no documentation - lot's of
> rubbish and unused stuff.
> I'm managing a project focusing on data quality that covers code
> changes, alterations to DTS packages, schema changes etc etc.
> What I'd like to do is see where the bit I want to change is being
> used.
> that might mean what stored procs use a field and what sprocs use that
> sproc.
> maybe it's which dts packages use a sproc (and again up the
> hieararchy)
> The list is a long one but basically I need to know what the effects
> are of changes.
> Is there a tool out there that lets me navigate a database to that
> level of detail - I understand something along the same lines is
> available for MS Access but I can't find it for SQL Server.
> Thanks
>|||On 26 Feb, 22:54, David Markle <new...@.markleconsulting.c0m> wrote:
> Red-Gate has a pretty cool tool called SQL Dependency Tracker that you
> should check out:
> http://www.red-gate.com/products/SQL_Dependency_Tracker/index.htm
> There's also a stored proc in SQL Server called sp_depends which queries
> an internal view called sysdepends. You can also check that out if you
> want to spend $0 on new software. A warning: sysdepends is not that
> reliable, or at least it hasn't been for me in the past. I don't really
> know if SQL Server 2005 makes it more useful than it was in 2000. Does
> anyone on the group know if there have been any significant enhancements
> to sysdepends in 2005?
>
> oliver wrote:
> > Our database(s) are all over the place - no documentation - lot's of
> > rubbish and unused stuff.
> > I'm managing a project focusing on data quality that covers code
> > changes, alterations to DTS packages, schema changes etc etc.
> > What I'd like to do is see where the bit I want to change is being
> > used.
> > that might mean what stored procs use a field and what sprocs use that
> > sproc.
> > maybe it's which dts packages use a sproc (and again up the
> > hieararchy)
> > The list is a long one but basically I need to know what the effects
> > are of changes.
> > Is there a tool out there that lets me navigate a database to that
> > level of detail - I understand something along the same lines is
> > available for MS Access but I can't find it for SQL Server.
> > Thanks- Hide quoted text -
> - Show quoted text -
it's not really fully featured enough I don' think - money's not
really too much of an issue - surely there something a bit more meaty?
rubbish and unused stuff.
I'm managing a project focusing on data quality that covers code
changes, alterations to DTS packages, schema changes etc etc.
What I'd like to do is see where the bit I want to change is being
used.
that might mean what stored procs use a field and what sprocs use that
sproc.
maybe it's which dts packages use a sproc (and again up the
hieararchy)
The list is a long one but basically I need to know what the effects
are of changes.
Is there a tool out there that lets me navigate a database to that
level of detail - I understand something along the same lines is
available for MS Access but I can't find it for SQL Server.
ThanksRed-Gate has a pretty cool tool called SQL Dependency Tracker that you
should check out:
http://www.red-gate.com/products/SQL_Dependency_Tracker/index.htm
There's also a stored proc in SQL Server called sp_depends which queries
an internal view called sysdepends. You can also check that out if you
want to spend $0 on new software. A warning: sysdepends is not that
reliable, or at least it hasn't been for me in the past. I don't really
know if SQL Server 2005 makes it more useful than it was in 2000. Does
anyone on the group know if there have been any significant enhancements
to sysdepends in 2005?
oliver wrote:
> Our database(s) are all over the place - no documentation - lot's of
> rubbish and unused stuff.
> I'm managing a project focusing on data quality that covers code
> changes, alterations to DTS packages, schema changes etc etc.
> What I'd like to do is see where the bit I want to change is being
> used.
> that might mean what stored procs use a field and what sprocs use that
> sproc.
> maybe it's which dts packages use a sproc (and again up the
> hieararchy)
> The list is a long one but basically I need to know what the effects
> are of changes.
> Is there a tool out there that lets me navigate a database to that
> level of detail - I understand something along the same lines is
> available for MS Access but I can't find it for SQL Server.
> Thanks
>|||On 26 Feb, 22:54, David Markle <new...@.markleconsulting.c0m> wrote:
> Red-Gate has a pretty cool tool called SQL Dependency Tracker that you
> should check out:
> http://www.red-gate.com/products/SQL_Dependency_Tracker/index.htm
> There's also a stored proc in SQL Server called sp_depends which queries
> an internal view called sysdepends. You can also check that out if you
> want to spend $0 on new software. A warning: sysdepends is not that
> reliable, or at least it hasn't been for me in the past. I don't really
> know if SQL Server 2005 makes it more useful than it was in 2000. Does
> anyone on the group know if there have been any significant enhancements
> to sysdepends in 2005?
>
> oliver wrote:
> > Our database(s) are all over the place - no documentation - lot's of
> > rubbish and unused stuff.
> > I'm managing a project focusing on data quality that covers code
> > changes, alterations to DTS packages, schema changes etc etc.
> > What I'd like to do is see where the bit I want to change is being
> > used.
> > that might mean what stored procs use a field and what sprocs use that
> > sproc.
> > maybe it's which dts packages use a sproc (and again up the
> > hieararchy)
> > The list is a long one but basically I need to know what the effects
> > are of changes.
> > Is there a tool out there that lets me navigate a database to that
> > level of detail - I understand something along the same lines is
> > available for MS Access but I can't find it for SQL Server.
> > Thanks- Hide quoted text -
> - Show quoted text -
it's not really fully featured enough I don' think - money's not
really too much of an issue - surely there something a bit more meaty?
maintaining a database?
Our database(s) are all over the place - no documentation - lot's of
rubbish and unused stuff.
I'm managing a project focusing on data quality that covers code
changes, alterations to DTS packages, schema changes etc etc.
rubbish and unused stuff.
I'm managing a project focusing on data quality that covers code
changes, alterations to DTS packages, schema changes etc etc.
What I'd like to do is see where the bit I want to change is being
used.
that might mean what stored procs use a field and what sprocs use that
sproc.
maybe it's which dts packages use a sproc (and again up the
hieararchy)
The list is a long one but basically I need to know what the effects
are of changes.
Is there a tool out there that lets me navigate a database to that
level of detail - I understand something along the same lines is
available for MS Access but I can't find it for SQL Server.
ThanksObviously you could run traces while the db is running-- although this could
cause some resource descrease.
You could also do direct searches in all the sys tables for instances of the
keywords you are using
--
Jack Vamvas
___________________________________
The latest IT jobs - www.ITjobfeed.com
<a href="http://links.10026.com/?link=http://www.itjobfeed.com">UK IT Jobs</a>
<oraustin@.hotmail.comwrote in message
news:1172498745.473644.252660@.t69g2000cwt.googlegr oups.com...
Quote:
Originally Posted by
Our database(s) are all over the place - no documentation - lot's of
rubbish and unused stuff.
I'm managing a project focusing on data quality that covers code
changes, alterations to DTS packages, schema changes etc etc.
>
What I'd like to do is see where the bit I want to change is being
used.
that might mean what stored procs use a field and what sprocs use that
sproc.
maybe it's which dts packages use a sproc (and again up the
hieararchy)
>
The list is a long one but basically I need to know what the effects
are of changes.
Is there a tool out there that lets me navigate a database to that
level of detail - I understand something along the same lines is
available for MS Access but I can't find it for SQL Server.
>
Thanks
>
Wednesday, March 7, 2012
Mail notifications for scheduled jobs
I have a sql server 2000 sp3a box with 4 named instances.
I have read all of the articles and I cannot get the 'send mail' stuff working.
I have a mailbox associated with the Domanin account that starts the sql server and sql server agent services. I installed Outlook and created a mail profile for this account. I bounced the SQL server agent on one of the Instances but when I go into the properties for the Agent, on the General Tab, the option to choose a mail profile is GREYED out. I tried 'xp_startmail' and I get this error: xp_startmail: failed with mail error 0x80040111
can anyone help???Are you logging on to the server as the account SQL runs under? You will need to be logged onto to the server with the service account in order to set the mail properties in the agent|||are you sure you have covered all of the basics. does the sql and sql agent services run under a network account that maps to the exchange account you are attempting to use?
have you attempted to use the outlook client installed on the db server.|||You've got about 9 months until maintstream support for SQL 2000 ends. Upgrade to SQL 2005 and use the Database Mail feature (a lightweight SMTP client, instead of the clunky MAPI compliant interface).
In case that is not an option, here are some MS KB articles on SQL 2000 and setting up mail profiles.
http://support.microsoft.com/kb/315886
http://support.microsoft.com/default.aspx/kb/281293
http://support.microsoft.com/kb/263556/EN-US/
Some CRITICAL things to remember:
1. Outlook is single-threaded; if it pops an error message at the console, it can and will lock up SQL's job system.
2. SQL Mail and SQL Agent mail do not have to use the same profile. However, you must set up each profile separately (ie, to use alerts you must set up SQL Agent Mail, to use xp_sendmail you must set up SQL Mail). The two features are set up in different places (SQL Agent mail is set up by right-clicking on SQL Agent and selecting properties; SQL Mail is set up under support services).
3. You will have to configure SQL Mail/SQL Agent Mail separately for each instance. You might want to consider a separate profile for each. Be careful of the overhead associated with running four MAPI client instances (plus for SQL instances) on the same server.
Having said all that, I don't really recommed using SQL Agent Mail or SQL mail on a production server. Like I said, upgrade to SQL 2005.
Regards,
hmscott
I have read all of the articles and I cannot get the 'send mail' stuff working.
I have a mailbox associated with the Domanin account that starts the sql server and sql server agent services. I installed Outlook and created a mail profile for this account. I bounced the SQL server agent on one of the Instances but when I go into the properties for the Agent, on the General Tab, the option to choose a mail profile is GREYED out. I tried 'xp_startmail' and I get this error: xp_startmail: failed with mail error 0x80040111
can anyone help???Are you logging on to the server as the account SQL runs under? You will need to be logged onto to the server with the service account in order to set the mail properties in the agent|||are you sure you have covered all of the basics. does the sql and sql agent services run under a network account that maps to the exchange account you are attempting to use?
have you attempted to use the outlook client installed on the db server.|||You've got about 9 months until maintstream support for SQL 2000 ends. Upgrade to SQL 2005 and use the Database Mail feature (a lightweight SMTP client, instead of the clunky MAPI compliant interface).
In case that is not an option, here are some MS KB articles on SQL 2000 and setting up mail profiles.
http://support.microsoft.com/kb/315886
http://support.microsoft.com/default.aspx/kb/281293
http://support.microsoft.com/kb/263556/EN-US/
Some CRITICAL things to remember:
1. Outlook is single-threaded; if it pops an error message at the console, it can and will lock up SQL's job system.
2. SQL Mail and SQL Agent mail do not have to use the same profile. However, you must set up each profile separately (ie, to use alerts you must set up SQL Agent Mail, to use xp_sendmail you must set up SQL Mail). The two features are set up in different places (SQL Agent mail is set up by right-clicking on SQL Agent and selecting properties; SQL Mail is set up under support services).
3. You will have to configure SQL Mail/SQL Agent Mail separately for each instance. You might want to consider a separate profile for each. Be careful of the overhead associated with running four MAPI client instances (plus for SQL instances) on the same server.
Having said all that, I don't really recommed using SQL Agent Mail or SQL mail on a production server. Like I said, upgrade to SQL 2005.
Regards,
hmscott
Subscribe to:
Posts (Atom)