where is the actual physical location of views, sp's and dts packages?
The same place as was mention when you asked this question 4 times ago. :-)
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
Showing posts with label views. Show all posts
Showing posts with label views. Show all posts
Thursday, March 22, 2012
architecture
where is the actual physical location of views, sp's and dts packages?
Views and stored procs are objects within a database. Their definitions are
stored in sysobjects, syscomments, and others system tables within their
database. Physical storage is in the data files.
DTS package definitions are stored in msdb. Look for system tables named
like 'sysdts%'. Physical storage will be in the msdb data file.
DTS packages
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
sql
Views and stored procs are objects within a database. Their definitions are
stored in sysobjects, syscomments, and others system tables within their
database. Physical storage is in the data files.
DTS package definitions are stored in msdb. Look for system tables named
like 'sysdts%'. Physical storage will be in the msdb data file.
DTS packages
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
sql
architecture
where is the actual physical location of views, sp's and dts packages?
as far as I know, views and sps are part of your database file (.mdf) stored
as objects with the system tables. Typically a view is thought of as a
virtual table, or a stored query. The results of using a view are not
permanently stored in the database. The data accessed through a view is
actually constructed using standard T-SQL select command and can come from
one to many different base tables or even other views.
I hope this helps...
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
as far as I know, views and sps are part of your database file (.mdf) stored
as objects with the system tables. Typically a view is thought of as a
virtual table, or a stored query. The results of using a view are not
permanently stored in the database. The data accessed through a view is
actually constructed using standard T-SQL select command and can come from
one to many different base tables or even other views.
I hope this helps...
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
architecture
Where are views, dts packages stored..
ie where would the actual pysical location of vies and dts packages be
Views and stored procedures are in the syscomments table. DTS packages are
in the MSDB database.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
"mat" <mat@.discussions.microsoft.com> wrote in message
news:37BD3C41-73C3-4F81-AAFA-3E823244BBF4@.microsoft.com...
> Where are views, dts packages stored..
> ie where would the actual pysical location of vies and dts packages be
ie where would the actual pysical location of vies and dts packages be
Views and stored procedures are in the syscomments table. DTS packages are
in the MSDB database.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
"mat" <mat@.discussions.microsoft.com> wrote in message
news:37BD3C41-73C3-4F81-AAFA-3E823244BBF4@.microsoft.com...
> Where are views, dts packages stored..
> ie where would the actual pysical location of vies and dts packages be
architecture
Where are views, dts packages stored..
ie where would the actual pysical location of vies and dts packages beViews and stored procedures are in the syscomments table. DTS packages are
in the MSDB database.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"mat" <mat@.discussions.microsoft.com> wrote in message
news:37BD3C41-73C3-4F81-AAFA-3E823244BBF4@.microsoft.com...
> Where are views, dts packages stored..
> ie where would the actual pysical location of vies and dts packages be
ie where would the actual pysical location of vies and dts packages beViews and stored procedures are in the syscomments table. DTS packages are
in the MSDB database.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"mat" <mat@.discussions.microsoft.com> wrote in message
news:37BD3C41-73C3-4F81-AAFA-3E823244BBF4@.microsoft.com...
> Where are views, dts packages stored..
> ie where would the actual pysical location of vies and dts packages be
architecture
where is the actual physical location of views, sp's and dts packages?Views and stored procs are objects within a database. Their definitions are
stored in sysobjects, syscomments, and others system tables within their
database. Physical storage is in the data files.
DTS package definitions are stored in msdb. Look for system tables named
like 'sysdts%'. Physical storage will be in the msdb data file.
DTS packages
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
stored in sysobjects, syscomments, and others system tables within their
database. Physical storage is in the data files.
DTS package definitions are stored in msdb. Look for system tables named
like 'sysdts%'. Physical storage will be in the msdb data file.
DTS packages
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
architecture
Where are views, dts packages stored..
ie where would the actual pysical location of vies and dts packages beViews and stored procedures are in the syscomments table. DTS packages are
in the MSDB database.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"mat" <mat@.discussions.microsoft.com> wrote in message
news:37BD3C41-73C3-4F81-AAFA-3E823244BBF4@.microsoft.com...
> Where are views, dts packages stored..
> ie where would the actual pysical location of vies and dts packages besql
ie where would the actual pysical location of vies and dts packages beViews and stored procedures are in the syscomments table. DTS packages are
in the MSDB database.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"mat" <mat@.discussions.microsoft.com> wrote in message
news:37BD3C41-73C3-4F81-AAFA-3E823244BBF4@.microsoft.com...
> Where are views, dts packages stored..
> ie where would the actual pysical location of vies and dts packages besql
architecture
where is the actual physical location of views, sp's and dts packages?Views and stored procs are objects within a database. Their definitions are
stored in sysobjects, syscomments, and others system tables within their
database. Physical storage is in the data files.
DTS package definitions are stored in msdb. Look for system tables named
like 'sysdts%'. Physical storage will be in the msdb data file.
DTS packages
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
stored in sysobjects, syscomments, and others system tables within their
database. Physical storage is in the data files.
DTS package definitions are stored in msdb. Look for system tables named
like 'sysdts%'. Physical storage will be in the msdb data file.
DTS packages
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
architecture
where is the actual physical location of views, sp's and dts packages?as far as I know, views and sps are part of your database file (.mdf) stored
as objects with the system tables. Typically a view is thought of as a
virtual table, or a stored query. The results of using a view are not
permanently stored in the database. The data accessed through a view is
actually constructed using standard T-SQL select command and can come from
one to many different base tables or even other views.
I hope this helps...
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
as objects with the system tables. Typically a view is thought of as a
virtual table, or a stored query. The results of using a view are not
permanently stored in the database. The data accessed through a view is
actually constructed using standard T-SQL select command and can come from
one to many different base tables or even other views.
I hope this helps...
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
architecture
where is the actual physical location of views, sp's and dts packages?The same place as was mention when you asked this question 4 times ago. :-)
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
"mat" wrote:
> where is the actual physical location of views, sp's and dts packages?
Monday, March 19, 2012
Applying criteria at the start of a series of views
I have a series of views that provide a final result set e.g view 5 is select
... from view4; View 4 is select ... from view3 etc.
That all works fine, but what this does is include all of the data from
whatever tables are involved even though I need a subset. My typical
scenario is that the majority of the data are in the table(s) involved in the
initial view(s)
What I would like to do is pass the necessary parameters to the view(s)
involved so as to limit the amount of data that gets passed along. I'm still
learning the right way to do things in SQL, so I appreciate any insights that
anyone can provide.
TIA,
John"DevalilaJohn" <DevalilaJohn@.discussions.microsoft.com> wrote in message
news:098BB47D-453F-4B0A-A2E2-B843B10F30AA@.microsoft.com...
>I have a series of views that provide a final result set e.g view 5 is
>select
> ... from view4; View 4 is select ... from view3 etc.
> That all works fine, but what this does is include all of the data from
> whatever tables are involved even though I need a subset. My typical
> scenario is that the majority of the data are in the table(s) involved in
> the
> initial view(s)
> What I would like to do is pass the necessary parameters to the view(s)
> involved so as to limit the amount of data that gets passed along. I'm
> still
> learning the right way to do things in SQL, so I appreciate any insights
> that
> anyone can provide.
>
SQL Server will pass where-clause predicates down through views to the base
tables if it can. If the column in a view is the result of an expression,
however, this won't work.
David
... from view4; View 4 is select ... from view3 etc.
That all works fine, but what this does is include all of the data from
whatever tables are involved even though I need a subset. My typical
scenario is that the majority of the data are in the table(s) involved in the
initial view(s)
What I would like to do is pass the necessary parameters to the view(s)
involved so as to limit the amount of data that gets passed along. I'm still
learning the right way to do things in SQL, so I appreciate any insights that
anyone can provide.
TIA,
John"DevalilaJohn" <DevalilaJohn@.discussions.microsoft.com> wrote in message
news:098BB47D-453F-4B0A-A2E2-B843B10F30AA@.microsoft.com...
>I have a series of views that provide a final result set e.g view 5 is
>select
> ... from view4; View 4 is select ... from view3 etc.
> That all works fine, but what this does is include all of the data from
> whatever tables are involved even though I need a subset. My typical
> scenario is that the majority of the data are in the table(s) involved in
> the
> initial view(s)
> What I would like to do is pass the necessary parameters to the view(s)
> involved so as to limit the amount of data that gets passed along. I'm
> still
> learning the right way to do things in SQL, so I appreciate any insights
> that
> anyone can provide.
>
SQL Server will pass where-clause predicates down through views to the base
tables if it can. If the column in a view is the result of an expression,
however, this won't work.
David
Applying criteria at the start of a series of views
I have a series of views that provide a final result set e.g view 5 is select
... from view4; View 4 is select ... from view3 etc.
That all works fine, but what this does is include all of the data from
whatever tables are involved even though I need a subset. My typical
scenario is that the majority of the data are in the table(s) involved in the
initial view(s)
What I would like to do is pass the necessary parameters to the view(s)
involved so as to limit the amount of data that gets passed along. I'm still
learning the right way to do things in SQL, so I appreciate any insights that
anyone can provide.
TIA,
John
"DevalilaJohn" <DevalilaJohn@.discussions.microsoft.com> wrote in message
news:098BB47D-453F-4B0A-A2E2-B843B10F30AA@.microsoft.com...
>I have a series of views that provide a final result set e.g view 5 is
>select
> ... from view4; View 4 is select ... from view3 etc.
> That all works fine, but what this does is include all of the data from
> whatever tables are involved even though I need a subset. My typical
> scenario is that the majority of the data are in the table(s) involved in
> the
> initial view(s)
> What I would like to do is pass the necessary parameters to the view(s)
> involved so as to limit the amount of data that gets passed along. I'm
> still
> learning the right way to do things in SQL, so I appreciate any insights
> that
> anyone can provide.
>
SQL Server will pass where-clause predicates down through views to the base
tables if it can. If the column in a view is the result of an expression,
however, this won't work.
David
... from view4; View 4 is select ... from view3 etc.
That all works fine, but what this does is include all of the data from
whatever tables are involved even though I need a subset. My typical
scenario is that the majority of the data are in the table(s) involved in the
initial view(s)
What I would like to do is pass the necessary parameters to the view(s)
involved so as to limit the amount of data that gets passed along. I'm still
learning the right way to do things in SQL, so I appreciate any insights that
anyone can provide.
TIA,
John
"DevalilaJohn" <DevalilaJohn@.discussions.microsoft.com> wrote in message
news:098BB47D-453F-4B0A-A2E2-B843B10F30AA@.microsoft.com...
>I have a series of views that provide a final result set e.g view 5 is
>select
> ... from view4; View 4 is select ... from view3 etc.
> That all works fine, but what this does is include all of the data from
> whatever tables are involved even though I need a subset. My typical
> scenario is that the majority of the data are in the table(s) involved in
> the
> initial view(s)
> What I would like to do is pass the necessary parameters to the view(s)
> involved so as to limit the amount of data that gets passed along. I'm
> still
> learning the right way to do things in SQL, so I appreciate any insights
> that
> anyone can provide.
>
SQL Server will pass where-clause predicates down through views to the base
tables if it can. If the column in a view is the result of an expression,
however, this won't work.
David
Applying criteria at the start of a series of views
I have a series of views that provide a final result set e.g view 5 is selec
t
... from view4; View 4 is select ... from view3 etc.
That all works fine, but what this does is include all of the data from
whatever tables are involved even though I need a subset. My typical
scenario is that the majority of the data are in the table(s) involved in th
e
initial view(s)
What I would like to do is pass the necessary parameters to the view(s)
involved so as to limit the amount of data that gets passed along. I'm stil
l
learning the right way to do things in SQL, so I appreciate any insights tha
t
anyone can provide.
TIA,
John"DevalilaJohn" <DevalilaJohn@.discussions.microsoft.com> wrote in message
news:098BB47D-453F-4B0A-A2E2-B843B10F30AA@.microsoft.com...
>I have a series of views that provide a final result set e.g view 5 is
>select
> ... from view4; View 4 is select ... from view3 etc.
> That all works fine, but what this does is include all of the data from
> whatever tables are involved even though I need a subset. My typical
> scenario is that the majority of the data are in the table(s) involved in
> the
> initial view(s)
> What I would like to do is pass the necessary parameters to the view(s)
> involved so as to limit the amount of data that gets passed along. I'm
> still
> learning the right way to do things in SQL, so I appreciate any insights
> that
> anyone can provide.
>
SQL Server will pass where-clause predicates down through views to the base
tables if it can. If the column in a view is the result of an expression,
however, this won't work.
David
t
... from view4; View 4 is select ... from view3 etc.
That all works fine, but what this does is include all of the data from
whatever tables are involved even though I need a subset. My typical
scenario is that the majority of the data are in the table(s) involved in th
e
initial view(s)
What I would like to do is pass the necessary parameters to the view(s)
involved so as to limit the amount of data that gets passed along. I'm stil
l
learning the right way to do things in SQL, so I appreciate any insights tha
t
anyone can provide.
TIA,
John"DevalilaJohn" <DevalilaJohn@.discussions.microsoft.com> wrote in message
news:098BB47D-453F-4B0A-A2E2-B843B10F30AA@.microsoft.com...
>I have a series of views that provide a final result set e.g view 5 is
>select
> ... from view4; View 4 is select ... from view3 etc.
> That all works fine, but what this does is include all of the data from
> whatever tables are involved even though I need a subset. My typical
> scenario is that the majority of the data are in the table(s) involved in
> the
> initial view(s)
> What I would like to do is pass the necessary parameters to the view(s)
> involved so as to limit the amount of data that gets passed along. I'm
> still
> learning the right way to do things in SQL, so I appreciate any insights
> that
> anyone can provide.
>
SQL Server will pass where-clause predicates down through views to the base
tables if it can. If the column in a view is the result of an expression,
however, this won't work.
David
Sunday, February 19, 2012
Append Views
My Problem is
I have 2 views --> 2 Databases (2 Products) but there are same fields (Same structure)
and I have to created the report by Crystal Reports to compare the Quatity of all product in my Company
So how Can I combine them (2 views with the same recoed but not the same data)
thanks for helping me
Kate
You can try Linked Servers if your databases are on different servers or on different instances.
If they are on the same instance then you can use
select * from DatabaseName.dbo.TableName
OR
select * from DatabaseName..TableName
Eralper
Thursday, February 16, 2012
Append (?) query
I'm trying to join 8 views (ViewA, ViewB, etc...) together
into one new table. All the views have 3 columns (ID,
result1, result2), as does the destination table. I'm
currently trying this method -
SELECT * INTO [dbo].[ANewTable] FROM [dbo].[ViewA]
SELECT * INTO [dbo].[ANewTable] FROM [dbo].[ViewB]
...etc...
but only ViewA is added to ANewTable and I get the error
message -
'There is already an object named 'ANewTable' in the
database.'
Any advice on how to resolve this would be greatly
appreciated.
Thanks.
1: Do a UNION between the SELECT statements:
SELECT col1, col2, ... FROM ViewA
UNION ALL
SELECT col1, col2, ... FROM ViewB
UNION ALL
SELECT col1, col2, ... FROM ViewC
2. Once that is sorted out and gives correct result, use it as a derived table:
SELECT col1, col2, ...
INTO aNewTable
FROM
(
<the above code goes here>
) AS d
Each SELECT INTO creates a new table, you cannot have several using the same table name. Also, don't
use SELECT *, that is begging for trouble in the future...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"hagglingchad" <anonymous@.discussions.microsoft.com> wrote in message
news:088b01c4a608$d2b2f830$a401280a@.phx.gbl...
> I'm trying to join 8 views (ViewA, ViewB, etc...) together
> into one new table. All the views have 3 columns (ID,
> result1, result2), as does the destination table. I'm
> currently trying this method -
> SELECT * INTO [dbo].[ANewTable] FROM [dbo].[ViewA]
> SELECT * INTO [dbo].[ANewTable] FROM [dbo].[ViewB]
> ...etc...
> but only ViewA is added to ANewTable and I get the error
> message -
> 'There is already an object named 'ANewTable' in the
> database.'
> Any advice on how to resolve this would be greatly
> appreciated.
> Thanks.
|||Tibor,
This is great. Thanks very much. However, I'm not quite
sure of the relevance of 'AS d'.
Chad
>--Original Message--
>1: Do a UNION between the SELECT statements:
>SELECT col1, col2, ... FROM ViewA
>UNION ALL
>SELECT col1, col2, ... FROM ViewB
>UNION ALL
>SELECT col1, col2, ... FROM ViewC
>2. Once that is sorted out and gives correct result, use
it as a derived table:
>SELECT col1, col2, ...
>INTO aNewTable
>FROM
>(
><the above code goes here>
>) AS d
>
>Each SELECT INTO creates a new table, you cannot have
several using the same table name. Also, don't
>use SELECT *, that is begging for trouble in the future...
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>http://www.solidqualitylearning.com/
>
>"hagglingchad" <anonymous@.discussions.microsoft.com>
wrote in message[vbcol=seagreen]
>news:088b01c4a608$d2b2f830$a401280a@.phx.gbl...
together
>
>.
>
|||That is just an alias name for the derived table. Same as in below:
FROM tbla AS a JOIN tblb AS b
For a derived table, you *need* to define such a "correlation" name. Syntax requires it.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"hagglingchad" <anonymous@.discussions.microsoft.com> wrote in message
news:14f401c4a615$b83324a0$a601280a@.phx.gbl...[vbcol=seagreen]
> Tibor,
> This is great. Thanks very much. However, I'm not quite
> sure of the relevance of 'AS d'.
> Chad
> it as a derived table:
> several using the same table name. Also, don't
> wrote in message
> together
into one new table. All the views have 3 columns (ID,
result1, result2), as does the destination table. I'm
currently trying this method -
SELECT * INTO [dbo].[ANewTable] FROM [dbo].[ViewA]
SELECT * INTO [dbo].[ANewTable] FROM [dbo].[ViewB]
...etc...
but only ViewA is added to ANewTable and I get the error
message -
'There is already an object named 'ANewTable' in the
database.'
Any advice on how to resolve this would be greatly
appreciated.
Thanks.
1: Do a UNION between the SELECT statements:
SELECT col1, col2, ... FROM ViewA
UNION ALL
SELECT col1, col2, ... FROM ViewB
UNION ALL
SELECT col1, col2, ... FROM ViewC
2. Once that is sorted out and gives correct result, use it as a derived table:
SELECT col1, col2, ...
INTO aNewTable
FROM
(
<the above code goes here>
) AS d
Each SELECT INTO creates a new table, you cannot have several using the same table name. Also, don't
use SELECT *, that is begging for trouble in the future...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"hagglingchad" <anonymous@.discussions.microsoft.com> wrote in message
news:088b01c4a608$d2b2f830$a401280a@.phx.gbl...
> I'm trying to join 8 views (ViewA, ViewB, etc...) together
> into one new table. All the views have 3 columns (ID,
> result1, result2), as does the destination table. I'm
> currently trying this method -
> SELECT * INTO [dbo].[ANewTable] FROM [dbo].[ViewA]
> SELECT * INTO [dbo].[ANewTable] FROM [dbo].[ViewB]
> ...etc...
> but only ViewA is added to ANewTable and I get the error
> message -
> 'There is already an object named 'ANewTable' in the
> database.'
> Any advice on how to resolve this would be greatly
> appreciated.
> Thanks.
|||Tibor,
This is great. Thanks very much. However, I'm not quite
sure of the relevance of 'AS d'.
Chad
>--Original Message--
>1: Do a UNION between the SELECT statements:
>SELECT col1, col2, ... FROM ViewA
>UNION ALL
>SELECT col1, col2, ... FROM ViewB
>UNION ALL
>SELECT col1, col2, ... FROM ViewC
>2. Once that is sorted out and gives correct result, use
it as a derived table:
>SELECT col1, col2, ...
>INTO aNewTable
>FROM
>(
><the above code goes here>
>) AS d
>
>Each SELECT INTO creates a new table, you cannot have
several using the same table name. Also, don't
>use SELECT *, that is begging for trouble in the future...
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>http://www.solidqualitylearning.com/
>
>"hagglingchad" <anonymous@.discussions.microsoft.com>
wrote in message[vbcol=seagreen]
>news:088b01c4a608$d2b2f830$a401280a@.phx.gbl...
together
>
>.
>
|||That is just an alias name for the derived table. Same as in below:
FROM tbla AS a JOIN tblb AS b
For a derived table, you *need* to define such a "correlation" name. Syntax requires it.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"hagglingchad" <anonymous@.discussions.microsoft.com> wrote in message
news:14f401c4a615$b83324a0$a601280a@.phx.gbl...[vbcol=seagreen]
> Tibor,
> This is great. Thanks very much. However, I'm not quite
> sure of the relevance of 'AS d'.
> Chad
> it as a derived table:
> several using the same table name. Also, don't
> wrote in message
> together
Subscribe to:
Posts (Atom)