pros/cons of using Default instance and Named instance for Prod Se

Hi,
What is the pros and cons of using Default instance and Named instance for
Production Server?
I have been working with Default and I had no need for named instances.
We have a physical/vm servers for all environments.
Production always have a physical server.
So I have not needed a named instance.
What do you recommend to use in Production?
Thanks in advance.SQLapprentice wrote:
> Hi,
> What is the pros and cons of using Default instance and Named
> instance for Production Server?
> I have been working with Default and I had no need for named
> instances. We have a physical/vm servers for all environments.
> Production always have a physical server.
> So I have not needed a named instance.
> What do you recommend to use in Production?
> Thanks in advance.
I don't believe it makes any difference. You can install named instances on
the same server without additional licensing concerns (there is a limit I
believe of 8). However, you cannot use a SQL Server on a VM without a valid
license.
David Gugick
Quest Software|||I vote for a named instance. The advantage of names instances is that
they isolate the physical from the logical. Failing to do that has
caused me countless problems over the years, so I never pass up a
chance to avoid repeating that mistake.
The payback comes with configurations you knew for certain would never
change, change anyway. Example: There are problems with your
production server and have to bring up your production database on a
different box. With names instances the name can move from one box to
the other. With default, you either have to change all the apps that
point to the server, or rename the server (and then name it back when
you shift back to the original server.)
Roy
On Tue, 15 Nov 2005 10:41:06 -0800, you wrote:

>Hi,
>What is the pros and cons of using Default instance and Named instance for
>Production Server?
>I have been working with Default and I had no need for named instances.
>We have a physical/vm servers for all environments.
>Production always have a physical server.
>So I have not needed a named instance.
>What do you recommend to use in Production?
>Thanks in advance.

Pros of having SQL server added to AD

What are the pros of having SQL Server instance added to Active Directory ?
I was looking at the server properties and saw the Active Directory tab and
had an option to add it.
What may be the cons ? Right now none of our SQL Servers are added. Do most
of you add the server to AD ? What am I missing by not doing so ? Thanks
Well, are you using AD for anything now? If not, it is unlikely that the
mere adding of SQL Server to AD will produce any tangible benefits.
What you get by adding SQL Server to AD are things like Service Publication,
which is just a fancy form of an alias or DNS, IMHO. For example, if SQL
Server is on myServer01, it can be published through AD, then you can move
the server and clients do not need to know that the server has moved...
Since, instead of using a hard-coded IP address or server name, you are
going through AD, and it is redirecting you based solely on the name of the
database you want to connect to. This means you will have to change your
applications (and expect to need this flexibility) before you will see this
benefit.
A few of the problems I see with the above approach:
(a) obviously with AD there are more security considerations, so it won't be
like SQL Server authentication anymore. Apps have to be rewritten and
protecting the directory might take a significant amount of work.
(b) in our environment we have several locations with the same database -
e.g. Dev, QA, Production. If I want to connect to the Sales database, I now
have to think about this differently. Instead of "just connect to the Sales
database on the QA server," I now have to give each one a distinct
publication name, such as QA-SalesDB. This isn't a difficult change, and in
fact in some lights it is better, but it is a change, and we know how some
people are resistant to even the smallest delta in mindset or approach.
(c) using SQL through ADSI versus directly through the OLEDB provider can
cause some problems with existing code (and habits that will lend to
continuing to write code this way). There is no longer the ability to use
SELECT * ... You must name your columns.
As in a previous thread, I strongly suggest you spend some time reading on
the subject. You'll be much better informed to make a decision than just
listening to opinions (which are not based at all on anything specific in
YOUR environment).
ADSI and using SQL Server through AD are documented in MSDN Online, as well
as several 3rd party web sites.
On 3/20/05 2:51 PM, in article #NqyHZYLFHA.732@.TK2MSFTNGP12.phx.gbl,
"Hassan" <fatima_ja@.hotmail.com> wrote:

> What are the pros of having SQL Server instance added to Active Directory ?
> I was looking at the server properties and saw the Active Directory tab and
> had an option to add it.
> What may be the cons ? Right now none of our SQL Servers are added. Do most
> of you add the server to AD ? What am I missing by not doing so ? Thanks
>

Pros of having SQL server added to AD

What are the pros of having SQL Server instance added to Active Directory ?
I was looking at the server properties and saw the Active Directory tab and
had an option to add it.
What may be the cons ? Right now none of our SQL Servers are added. Do most
of you add the server to AD ? What am I missing by not doing so ? ThanksWell, are you using AD for anything now? If not, it is unlikely that the
mere adding of SQL Server to AD will produce any tangible benefits.
What you get by adding SQL Server to AD are things like Service Publication,
which is just a fancy form of an alias or DNS, IMHO. For example, if SQL
Server is on myServer01, it can be published through AD, then you can move
the server and clients do not need to know that the server has moved...
Since, instead of using a hard-coded IP address or server name, you are
going through AD, and it is redirecting you based solely on the name of the
database you want to connect to. This means you will have to change your
applications (and expect to need this flexibility) before you will see this
benefit.
A few of the problems I see with the above approach:
(a) obviously with AD there are more security considerations, so it won't be
like SQL Server authentication anymore. Apps have to be rewritten and
protecting the directory might take a significant amount of work.
(b) in our environment we have several locations with the same database -
e.g. Dev, QA, Production. If I want to connect to the Sales database, I now
have to think about this differently. Instead of "just connect to the Sales
database on the QA server," I now have to give each one a distinct
publication name, such as QA-SalesDB. This isn't a difficult change, and in
fact in some lights it is better, but it is a change, and we know how some
people are resistant to even the smallest delta in mindset or approach.
(c) using SQL through ADSI versus directly through the OLEDB provider can
cause some problems with existing code (and habits that will lend to
continuing to write code this way). There is no longer the ability to use
SELECT * ... You must name your columns.
As in a previous thread, I strongly suggest you spend some time reading on
the subject. You'll be much better informed to make a decision than just
listening to opinions (which are not based at all on anything specific in
YOUR environment).
ADSI and using SQL Server through AD are documented in MSDN Online, as well
as several 3rd party web sites.
On 3/20/05 2:51 PM, in article #NqyHZYLFHA.732@.TK2MSFTNGP12.phx.gbl,
"Hassan" <fatima_ja@.hotmail.com> wrote:
> What are the pros of having SQL Server instance added to Active Directory ?
> I was looking at the server properties and saw the Active Directory tab and
> had an option to add it.
> What may be the cons ? Right now none of our SQL Servers are added. Do most
> of you add the server to AD ? What am I missing by not doing so ? Thanks
>sql

Pros of having SQL server added to AD

What are the pros of having SQL Server instance added to Active Directory ?
I was looking at the server properties and saw the Active Directory tab and
had an option to add it.
What may be the cons ? Right now none of our SQL Servers are added. Do most
of you add the server to AD ? What am I missing by not doing so ? ThanksWell, are you using AD for anything now? If not, it is unlikely that the
mere adding of SQL Server to AD will produce any tangible benefits.
What you get by adding SQL Server to AD are things like Service Publication,
which is just a fancy form of an alias or DNS, IMHO. For example, if SQL
Server is on myServer01, it can be published through AD, then you can move
the server and clients do not need to know that the server has moved...
Since, instead of using a hard-coded IP address or server name, you are
going through AD, and it is redirecting you based solely on the name of the
database you want to connect to. This means you will have to change your
applications (and expect to need this flexibility) before you will see this
benefit.
A few of the problems I see with the above approach:
(a) obviously with AD there are more security considerations, so it won't be
like SQL Server authentication anymore. Apps have to be rewritten and
protecting the directory might take a significant amount of work.
(b) in our environment we have several locations with the same database -
e.g. Dev, QA, Production. If I want to connect to the Sales database, I now
have to think about this differently. Instead of "just connect to the Sales
database on the QA server," I now have to give each one a distinct
publication name, such as QA-SalesDB. This isn't a difficult change, and in
fact in some lights it is better, but it is a change, and we know how some
people are resistant to even the smallest delta in mindset or approach.
(c) using SQL through ADSI versus directly through the OLEDB provider can
cause some problems with existing code (and habits that will lend to
continuing to write code this way). There is no longer the ability to use
SELECT * ... You must name your columns.
As in a previous thread, I strongly suggest you spend some time reading on
the subject. You'll be much better informed to make a decision than just
listening to opinions (which are not based at all on anything specific in
YOUR environment).
ADSI and using SQL Server through AD are documented in MSDN Online, as well
as several 3rd party web sites.
On 3/20/05 2:51 PM, in article #NqyHZYLFHA.732@.TK2MSFTNGP12.phx.gbl,
"Hassan" <fatima_ja@.hotmail.com> wrote:

> What are the pros of having SQL Server instance added to Active Directory
?
> I was looking at the server properties and saw the Active Directory tab an
d
> had an option to add it.
> What may be the cons ? Right now none of our SQL Servers are added. Do mos
t
> of you add the server to AD ? What am I missing by not doing so ? Thanks
>

Programmatically Deleting an Instance

I'm trying to just get a basic NS app up and running. While I can get through the samples just fine, it seems there are no samples that programmatically manage Instances/Applications, etc. I've googled around and not found anything either. Essentially it looks to me that everyone uses the IDF/ADF files. The SDK has some very sparse documentation on it, so I've started there and tried to get things working.

I have code to create the instance/application programmatically, but when I want to drop the whole thing and create it again, upon calling instance.Create() I get an exception (actually this is what the innerException says) saying:

Notification Services failed to read the NSVersionInfo table.

I’m following the example in the SDK (doing Disable/UnregisterLocal/Drop). Interestingly when I do the Disable/Unregister/Drop in SQL Management Studio it works fine. It's also interesting to note that when I ignore the exception it comes up once more, but after that the instance and associated databases seem to be created.

Here’s the short version of my code (getFreshInstance() is the entry method):

private void configureInstance(nmo.Instance instance)
{
prototypeApplication = new nmo.Application(instance, applicationName);

AddDeliveryChannels(instance);
configureApp(prototypeApplication);
instance.Applications.Add(prototypeApplication);
}

private void configureApp(nmo.Application app)
{
AddGenerator(app);
AddDistributor(app);
}

private void checkAndDrop(string name)
{
if (notificationServices.Instances.Contains(name))
{
nmo.Instance instance = new nmo.Instance(notificationServices, name);
instance.Refresh();

instance.Disable();
instance.UnregisterLocal();
instance.Drop();
}
}

private nmo.Instance getFreshInstance()
{
nmo.Instance instance = new nmo.Instance(notificationServices, instanceName);

checkAndDrop(instanceName);

configureInstance(instance);

instance.Create();
instance.RegisterLocal();
instance.Enable();

return instance;
}

Anyone know what I'm doing wrong?

Ok, seems you've asked a question not many folks in the wild know the answer to :-).

I've tracked down what is probably the answer care of Shyam Pather:

He’s creating a new in-memory object to reflect his instance, like this:

Nmo.Instance instance = new Nmo.Instance(…, “InstanceName”);

Instead, he should do something like:

Smo.Server s = new Smo.Server(…);

Nmo.Instance instance = s.NotificationServices.Instances[“InstanceName”];

That will get him an instance object that’s already populated with the metadata from the database and actually represents the existing instance.

The FlightNMO sample that comes with SQL Server 2005 should also provide you a working example of how to make the API calls.

Hope that helps,

-Lukasz

This posting is provided "AS IS" with no warranties, and confers no rights.

|||

I just gave that snippet a try and unfortunately, I ended up with the same error when I attempt to enable. The need for this functionality in my project has been removed by a change in design, so I'm no longer really worried about this, but I would still be curious to know the cause of this or hear confirmation of someone else running into this.

Now that you mention it, I vaguely remember seeing the FlightNMO sample when I first looked at NS, but had since forgotten it. Thanks! I'm sure that'll prove quite useful later. As far as this particular functionality though, I'm afraid FlightNMO doesn't ever delete the instance, only create.

Thanks for your help,

-Francis

Programmatic Render of Reports into PDF format

Hi,
Can anybody please convert the following C# code into VB.Net Code.I tried
but its saying Object Reference not set to an instance of an object.
Or give me VB.NET(Web Application, CodeBehind:VB.Net) code to
programmatically render reports into PDF format.
// Prepare report parameter.
ParameterValue[] parameters = new ParameterValue[1];
parameters[0] = new ParameterValue();
parameters[0].Name = "Parameter1";
parameters[0].Value = Request.QueryString["id"];
Thanks
Rajesh YDim Parameters(1) As New ParameterValue
Parameters(0) = New ParameterValue
Parameters(0).Name = "Parameter1"
Parameters(0).Value = Request.QueryString("id")
"Rajesh Yennam" wrote:
> Hi,
> Can anybody please convert the following C# code into VB.Net Code.I tried
> but its saying Object Reference not set to an instance of an object.
> Or give me VB.NET(Web Application, CodeBehind:VB.Net) code to
> programmatically render reports into PDF format.
> // Prepare report parameter.
> ParameterValue[] parameters = new ParameterValue[1];
> parameters[0] = new ParameterValue();
> parameters[0].Name = "Parameter1";
> parameters[0].Value = Request.QueryString["id"];
> Thanks
> Rajesh Y|||Hi Rajesh:
I'd suspect the line of code :
parameters[0].Value = Request.QueryString["id"];
I'd guess you do not have an id parameter in the query string. Double
check the query string.
HTH,
--
Scott
http://www.OdeToCode.com/blogs/scott/
On Fri, 29 Oct 2004 03:43:01 -0700, "Rajesh Yennam"
<RajeshYennam@.discussions.microsoft.com> wrote:
>Hi,
>Can anybody please convert the following C# code into VB.Net Code.I tried
>but its saying Object Reference not set to an instance of an object.
>Or give me VB.NET(Web Application, CodeBehind:VB.Net) code to
>programmatically render reports into PDF format.
>// Prepare report parameter.
> ParameterValue[] parameters = new ParameterValue[1];
> parameters[0] = new ParameterValue();
> parameters[0].Name = "Parameter1";
> parameters[0].Value = Request.QueryString["id"];
>Thanks
>Rajesh Y