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?

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

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?

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

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

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?

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

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?

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?

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?

applying snapshot from alternate location

Hi

We are using HTTPS merge replication - is it possible to specify an alternative location when applying the initial snapshot ?

Thanks
Bruce

yes, it's possible. Is it not working in your case?|||

I'm talking about where the subscriberType is anonymous if that helps...

Our setup is as follows...

subscription.CreateSyncAgentByDefault = False -- I wrote a windows service to synchronise
subscription.UseWebSynchronization = True
subscription.InternetSecurityMode = AuthenticationMethod.BasicAuthentication
subscription.SubscriberType = MergeSubscriberType.Anonymous

I can't see anything in the doco about specifying alternate snapshot location in this case (where subscription.SyncType = SubscriptionSyncType.None)

At the moment we are persisting with downloading the initial snapshot over the 'net - which for some of our clients in regional Australia takes forever - they are on horrible dial-up connections - it's the darkages in parts of this country !

So if I can download the initial snapshot locally to get them going it'll be a relief !

Thanks
Bruce

|||

Hi Bruce,

From your posts, I gather that you are using a no-sync subscription.

You can specify an alternate snapshot location. BOL has more info on that.

However in such a scenario, I do not see the need to download all the files because it is a no-sync subscription and need only few files. But due to a bug, we indeed do download all the files from the snapshot location.

So even if you do provide an alternate snapshot location, the files will still be downloaded even though all may not be applied.

I have seen this happen internally concurrently and I happened to read your post today.

I hope that we can fix it in the Service Pack 2 timeframe. Till then, you will have to bear ths burden of downloading the files.

applying snapshot from alternate location

Hi

We are using HTTPS merge replication - is it possible to specify an alternative location when applying the initial snapshot ?

Thanks
Bruce

yes, it's possible. Is it not working in your case?|||

I'm talking about where the subscriberType is anonymous if that helps...

Our setup is as follows...

subscription.CreateSyncAgentByDefault = False -- I wrote a windows service to synchronise
subscription.UseWebSynchronization = True
subscription.InternetSecurityMode = AuthenticationMethod.BasicAuthentication
subscription.SubscriberType = MergeSubscriberType.Anonymous

I can't see anything in the doco about specifying alternate snapshot location in this case (where subscription.SyncType = SubscriptionSyncType.None)

At the moment we are persisting with downloading the initial snapshot over the 'net - which for some of our clients in regional Australia takes forever - they are on horrible dial-up connections - it's the darkages in parts of this country !

So if I can download the initial snapshot locally to get them going it'll be a relief !

Thanks
Bruce

|||

Hi Bruce,

From your posts, I gather that you are using a no-sync subscription.

You can specify an alternate snapshot location. BOL has more info on that.

However in such a scenario, I do not see the need to download all the files because it is a no-sync subscription and need only few files. But due to a bug, we indeed do download all the files from the snapshot location.

So even if you do provide an alternate snapshot location, the files will still be downloaded even though all may not be applied.

I have seen this happen internally concurrently and I happened to read your post today.

I hope that we can fix it in the Service Pack 2 timeframe. Till then, you will have to bear ths burden of downloading the files.

Application Databases storing location

We have SQL Database in Cluster volume F:
Cluster volume is mounted in the primary server A1.
We have production and test databases of the applications
stored in the Cluster Storage F:.
Is it possible to store all the test databases of the
applications in the Clocal harddisk) of the primary
server?
If there is a solution pls advice.
You can copy data to anywhere you would like. To use the data with
clustering, you have to have the ability for that data to be reached by any
clustered node, even after a failure. If you keep anything local, and that
machine
fails, other nodes will not be able to access it.
Cheers,
Rod
"Anonymous" <anonymous@.discussions.microsoft.com> wrote in message
news:743201c430db$f3018270$a401280a@.phx.gbl...
> We have SQL Database in Cluster volume F:
> Cluster volume is mounted in the primary server A1.
> We have production and test databases of the applications
> stored in the Cluster Storage F:.
> Is it possible to store all the test databases of the
> applications in the Clocal harddisk) of the primary
> server?
> If there is a solution pls advice.
>
|||A clustered SQL server must store data on a drive that is in the same
resource group. The SQL server must be dependant on the physical disk(s)
that clustered data is stored on.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Anonymous" <anonymous@.discussions.microsoft.com> wrote in message
news:743201c430db$f3018270$a401280a@.phx.gbl...
> We have SQL Database in Cluster volume F:
> Cluster volume is mounted in the primary server A1.
> We have production and test databases of the applications
> stored in the Cluster Storage F:.
> Is it possible to store all the test databases of the
> applications in the Clocal harddisk) of the primary
> server?
> If there is a solution pls advice.
>
|||Can the Clocal harddisk) of the primary server be
included as part of the same resource group as the
clustered SQL server?

>--Original Message--
>A clustered SQL server must store data on a drive that is
in the same
>resource group. The SQL server must be dependant on the
physical disk(s)
>that clustered data is stored on.
>
>--
>Geoff N. Hiten
>Microsoft SQL Server MVP
>Senior Database Administrator
>Careerbuilder.com
>I support the Professional Association for SQL Server
>www.sqlpass.org
>"Anonymous" <anonymous@.discussions.microsoft.com> wrote
in message[vbcol=seagreen]
>news:743201c430db$f3018270$a401280a@.phx.gbl...
applications
>
>.
>
|||Fine. We do not want the test data in the cluster mode and
need not be available in case of failure.
Is it possible to have SQL server in Cluster and
applications data in the local?

>--Original Message--
>You can copy data to anywhere you would like. To use the
data with
>clustering, you have to have the ability for that data to
be reached by any
>clustered node, even after a failure. If you keep
anything local, and that
>machine
>fails, other nodes will not be able to access it.
>Cheers,
>Rod
>"Anonymous" <anonymous@.discussions.microsoft.com> wrote
in message[vbcol=seagreen]
>news:743201c430db$f3018270$a401280a@.phx.gbl...
applications
>
>.
>
|||No. C: is not a shared cluster resource.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Anonymous" <anonymous@.discussions.microsoft.com> wrote in message
news:886301c4326d$56ac1a00$a301280a@.phx.gbl...[vbcol=seagreen]
> Can the Clocal harddisk) of the primary server be
> included as part of the same resource group as the
> clustered SQL server?
> in the same
> physical disk(s)
> in message
> applications
|||No, sorry you can't do that. All SQL data needs to be on the shared storage.
Cheers,
Rod
"Anonymous" <anonymous@.discussions.microsoft.com> wrote in message
news:886b01c4326e$406dde30$a301280a@.phx.gbl...[vbcol=seagreen]
> Fine. We do not want the test data in the cluster mode and
> need not be available in case of failure.
> Is it possible to have SQL server in Cluster and
> applications data in the local?
> data with
> be reached by any
> anything local, and that
> in message
> applications