Best Practice question

Our company has several large 3rd-party applications, each with its' own
dedicated SQL Server database. I am developing our own add-ons and utilities
that use data from these databases.
My question is, should my Views, Functions & Stored Procedures reside in the
3rd-party database (they have a standard naming convention to identify our
code), or should they be in a separate database referencing the tables, views
etc. in the 3rd-party database?
Is there any loss in efficiency by keeping our code in a separate datebase?
We are using SQL 2000 Standard.
Thank you.I don't see a problem with keeping the objects in the third-party database
as long as you have a naming convention to identify the objects and are
prepared to re-apply scripts to re-create the objects, if needed. If you
keep objects in a separate database, you'll need to create users in both
databases and can't use ownership chaining unless you enable the
'db-chaining' database option in both databases.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in message
news:745D6B85-63D3-4194-9213-8721D7B3713D@.microsoft.com...
> Our company has several large 3rd-party applications, each with its' own
> dedicated SQL Server database. I am developing our own add-ons and
> utilities
> that use data from these databases.
> My question is, should my Views, Functions & Stored Procedures reside in
> the
> 3rd-party database (they have a standard naming convention to identify our
> code), or should they be in a separate database referencing the tables,
> views
> etc. in the 3rd-party database?
> Is there any loss in efficiency by keeping our code in a separate
> datebase?
> We are using SQL 2000 Standard.
> Thank you.|||Dan,
Thank you for the quick response. One thing I did not address was storing
data in custom tables in the 3rd party db which I am also doing. Because the
data in the custom tables changes more frequently than the 3rd party, I use
scheduled DTS packages to copy data from the custom tables to a separate db.
Any thoughts on that?
Thank you again.
--
"Dan Guzman" wrote:
> I don't see a problem with keeping the objects in the third-party database
> as long as you have a naming convention to identify the objects and are
> prepared to re-apply scripts to re-create the objects, if needed. If you
> keep objects in a separate database, you'll need to create users in both
> databases and can't use ownership chaining unless you enable the
> 'db-chaining' database option in both databases.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in message
> news:745D6B85-63D3-4194-9213-8721D7B3713D@.microsoft.com...
> > Our company has several large 3rd-party applications, each with its' own
> > dedicated SQL Server database. I am developing our own add-ons and
> > utilities
> > that use data from these databases.
> >
> > My question is, should my Views, Functions & Stored Procedures reside in
> > the
> > 3rd-party database (they have a standard naming convention to identify our
> > code), or should they be in a separate database referencing the tables,
> > views
> > etc. in the 3rd-party database?
> >
> > Is there any loss in efficiency by keeping our code in a separate
> > datebase?
> >
> > We are using SQL 2000 Standard.
> >
> > Thank you.
>|||> Any thoughts on that?
The main reason would might want to store the tables in a different database
is if you have a lot of data and the recovery/availability requirements are
different. Separation will give you more flexibility.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in message
news:A89EB44E-5E8C-4239-9E01-A92644E4EE3A@.microsoft.com...
> Dan,
> Thank you for the quick response. One thing I did not address was storing
> data in custom tables in the 3rd party db which I am also doing. Because
> the
> data in the custom tables changes more frequently than the 3rd party, I
> use
> scheduled DTS packages to copy data from the custom tables to a separate
> db.
> Any thoughts on that?
> Thank you again.
> --
> "Dan Guzman" wrote:
>> I don't see a problem with keeping the objects in the third-party
>> database
>> as long as you have a naming convention to identify the objects and are
>> prepared to re-apply scripts to re-create the objects, if needed. If you
>> keep objects in a separate database, you'll need to create users in both
>> databases and can't use ownership chaining unless you enable the
>> 'db-chaining' database option in both databases.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in
>> message
>> news:745D6B85-63D3-4194-9213-8721D7B3713D@.microsoft.com...
>> > Our company has several large 3rd-party applications, each with its'
>> > own
>> > dedicated SQL Server database. I am developing our own add-ons and
>> > utilities
>> > that use data from these databases.
>> >
>> > My question is, should my Views, Functions & Stored Procedures reside
>> > in
>> > the
>> > 3rd-party database (they have a standard naming convention to identify
>> > our
>> > code), or should they be in a separate database referencing the tables,
>> > views
>> > etc. in the 3rd-party database?
>> >
>> > Is there any loss in efficiency by keeping our code in a separate
>> > datebase?
>> >
>> > We are using SQL 2000 Standard.
>> >
>> > Thank you.|||Thank you.
--
"Dan Guzman" wrote:
> > Any thoughts on that?
> The main reason would might want to store the tables in a different database
> is if you have a lot of data and the recovery/availability requirements are
> different. Separation will give you more flexibility.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in message
> news:A89EB44E-5E8C-4239-9E01-A92644E4EE3A@.microsoft.com...
> > Dan,
> >
> > Thank you for the quick response. One thing I did not address was storing
> > data in custom tables in the 3rd party db which I am also doing. Because
> > the
> > data in the custom tables changes more frequently than the 3rd party, I
> > use
> > scheduled DTS packages to copy data from the custom tables to a separate
> > db.
> > Any thoughts on that?
> >
> > Thank you again.
> > --
> >
> > "Dan Guzman" wrote:
> >
> >> I don't see a problem with keeping the objects in the third-party
> >> database
> >> as long as you have a naming convention to identify the objects and are
> >> prepared to re-apply scripts to re-create the objects, if needed. If you
> >> keep objects in a separate database, you'll need to create users in both
> >> databases and can't use ownership chaining unless you enable the
> >> 'db-chaining' database option in both databases.
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "SQLGuptaSybase" <SQLGuptaSybase@.discussions.microsoft.com> wrote in
> >> message
> >> news:745D6B85-63D3-4194-9213-8721D7B3713D@.microsoft.com...
> >> > Our company has several large 3rd-party applications, each with its'
> >> > own
> >> > dedicated SQL Server database. I am developing our own add-ons and
> >> > utilities
> >> > that use data from these databases.
> >> >
> >> > My question is, should my Views, Functions & Stored Procedures reside
> >> > in
> >> > the
> >> > 3rd-party database (they have a standard naming convention to identify
> >> > our
> >> > code), or should they be in a separate database referencing the tables,
> >> > views
> >> > etc. in the 3rd-party database?
> >> >
> >> > Is there any loss in efficiency by keeping our code in a separate
> >> > datebase?
> >> >
> >> > We are using SQL 2000 Standard.
> >> >
> >> > Thank you.
> >>
>

Best Practice

We have a dedicated web server that runs SQL it is not hosted on our network
it is hosted by an ISP. We also run an inhouse SQL server. We need to get
info back and forth between the two DB's. What would be the best way to do
this securely.
Thank youA Scheduled DTS task. But, your table design needs to be able to handle such
a model.
You need a way to identify changed rows and a way to resolve them is they
were both changed between synchronization.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Ryan" <Ryan@.discussions.microsoft.com> wrote in message
news:4D58A22F-4269-4365-861C-DA7E202EFA04@.microsoft.com...
> We have a dedicated web server that runs SQL it is not hosted on our
> network
> it is hosted by an ISP. We also run an inhouse SQL server. We need to get
> info back and forth between the two DB's. What would be the best way to do
> this securely.
> Thank you|||Thank you for your reply one other question. Would the DTS package be secure
?
"Mike Epprecht (SQL MVP)" wrote:

> A Scheduled DTS task. But, your table design needs to be able to handle su
ch
> a model.
> You need a way to identify changed rows and a way to resolve them is they
> were both changed between synchronization.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Ryan" <Ryan@.discussions.microsoft.com> wrote in message
> news:4D58A22F-4269-4365-861C-DA7E202EFA04@.microsoft.com...
>
>

best back-up method?

i have a Dedicated SQL server running 2000Adv. and a
server running 2003SBS (premium)as my DC running a 75 pc
network.wanted to do a nightly SQL DB back-up to the SBS
and was wondering how i should go about it. I was
thinking i could make it a replication server and just
replicate nightly or "on the fly", second was to make a 2
node cluser but i didnt it was ok to do that with my DC,
and if it could, how could i test to see if my machine
can hanlde the required Throughput, without crashing the
Domain, Of course. i use the DC ro rung my Intranet
website, Office Server, Firewall management module, File
Replication. and didnt know if it was safe to run all
thoes apps, simultaniousely. ok, well my thanks for any
help or guidance you could give me.
Hi
You can't cluster it. You need SQL 2000 Enterprise Edition and Windows
2000/2003 Enterprise edition to do that.
On the SQL box, you can do a database backup to the local drive and then
have a job that copies it onto the SBS box every night.
--
Mike Epprecht, Microsoft SQL Server MVP
Epprecht Consulting (PTY) LTD
Johannesburg, South Africa
Mobile: +27-82-552-0268
IM: mike@.epprecht.net
Specialist SQL Server Solutions and Consulting
MVP Program: http://www.microsoft.com/mvp
"Justin" <Irclover1@.hotmail.com> wrote in message
news:2a4dc01c46647$843714d0$a401280a@.phx.gbl...
> i have a Dedicated SQL server running 2000Adv. and a
> server running 2003SBS (premium)as my DC running a 75 pc
> network.wanted to do a nightly SQL DB back-up to the SBS
> and was wondering how i should go about it. I was
> thinking i could make it a replication server and just
> replicate nightly or "on the fly", second was to make a 2
> node cluser but i didnt it was ok to do that with my DC,
> and if it could, how could i test to see if my machine
> can hanlde the required Throughput, without crashing the
> Domain, Of course. i use the DC ro rung my Intranet
> website, Office Server, Firewall management module, File
> Replication. and didnt know if it was safe to run all
> thoes apps, simultaniousely. ok, well my thanks for any
> help or guidance you could give me.