Showing posts with label library. Show all posts
Showing posts with label library. Show all posts

Tuesday, March 27, 2012

Cluster setup question

Im viewing the Cluster setup instructions at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht
_clustering_51rm.asp
But it doesnt say where to install SQL. It seems to me that if I wanted to
have an Active/ Passive Cluster I would need to intsall it on both boxes? Is
this correct? Are there better links I should be using?
--
SQL2K SP3
TIA, ChrisRYou begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>|||Well, that is close, but not quite accurate.
Even on a stand-alone installation, when you run the setup dialogue in
interactive mode, all that really happens is that a custom .iss file is
generated from your responses to the questions. Once all of the information
is gathered, setup then executes the setupsql with the newly created
setup.iss file as a parameter.
A cluster install is similar, except the setup.iss is deployed to both
nodes. During the installation, the cluster fails the disk over to each
node so that the individual setup.iss files can be ran against two
independently executed setupsql commands. This creates registry keys.
However, since the first install already created the directory structure,
deployed the binaries, installed the .sql scripts to master, model, and
msdb, this part of the process does not run again a second time. Just the
registry keys, performance counters, and client side tools. And, of course,
the MDAC, which is client side and IS NOT cluster aware.
Also, there is such a thing as the "Primary Node." This is nothing more
than the node from which you started the installation. It does not matter
which node you begin the installation on, as long as it is the node that
currently owns the disk resource you plan on installing SQL Server to.
However, it is important that you keep in mind which node this was.
This node will be the only one that maintains a record of the setup logs.
There is also special CLSIDs that only this node will contain that will not
propagate to the other. The nodes are close to the same configuration, BUT
NOT EXACT. This will be important in the future when you try to add
additional disk resources or swap out old disks for new, if you ever need to
modify or add an additional IP resource, or change the domain the cluster
belongs to. Keeping in mind which node was PRIMARY will only be to your
benefit.
Sincerely,
Anthony Thomas
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
You begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>|||I have had to change accounts and add/remove disk resources. As long as I
use the current owner node, everything works fine.
Yes, there are some subtle differences such as log files between nodes but
that is only relevant during installation failure troubleshooting. Once
everythign is running, there is no practical difference between nodes,
unlike SQL 7.0 clustering.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OfrkU8e$EHA.1084@.tk2msftngp13.phx.gbl...
> Well, that is close, but not quite accurate.
> Even on a stand-alone installation, when you run the setup dialogue in
> interactive mode, all that really happens is that a custom .iss file is
> generated from your responses to the questions. Once all of the
information
> is gathered, setup then executes the setupsql with the newly created
> setup.iss file as a parameter.
> A cluster install is similar, except the setup.iss is deployed to both
> nodes. During the installation, the cluster fails the disk over to each
> node so that the individual setup.iss files can be ran against two
> independently executed setupsql commands. This creates registry keys.
> However, since the first install already created the directory structure,
> deployed the binaries, installed the .sql scripts to master, model, and
> msdb, this part of the process does not run again a second time. Just the
> registry keys, performance counters, and client side tools. And, of
course,
> the MDAC, which is client side and IS NOT cluster aware.
> Also, there is such a thing as the "Primary Node." This is nothing more
> than the node from which you started the installation. It does not matter
> which node you begin the installation on, as long as it is the node that
> currently owns the disk resource you plan on installing SQL Server to.
> However, it is important that you keep in mind which node this was.
> This node will be the only one that maintains a record of the setup logs.
> There is also special CLSIDs that only this node will contain that will
not
> propagate to the other. The nodes are close to the same configuration,
BUT
> NOT EXACT. This will be important in the future when you try to add
> additional disk resources or swap out old disks for new, if you ever need
to
> modify or add an additional IP resource, or change the domain the cluster
> belongs to. Keeping in mind which node was PRIMARY will only be to your
> benefit.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
> You begin the installation from the node that currently owns the disk
> resource you want SQL data files installed to. You can add additional
disk
> resources after the installation. The SQL installer adds code
automagically
> to the nodes you specify, provided they actually exist and are running at
> install time. You can add or remove nodes from the SQL installation later
> if you need to. Once SQL is installed, there is no difference between
> installed nodes except for which one is actually running SQL at a given
> moment.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> > Im viewing the Cluster setup instructions at:
> >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht
> > _clustering_51rm.asp
> >
> > But it doesnt say where to install SQL. It seems to me that if I wanted
to
> > have an Active/ Passive Cluster I would need to intsall it on both
boxes?
> Is
> > this correct? Are there better links I should be using?
> >
> > --
> > SQL2K SP3
> >
> > TIA, ChrisR
> >
> >
>sqlsql

Cluster setup question

Im viewing the Cluster setup instructions at:
http://msdn.microsoft.com/library/de...us/howtosql/ht
_clustering_51rm.asp
But it doesnt say where to install SQL. It seems to me that if I wanted to
have an Active/ Passive Cluster I would need to intsall it on both boxes? Is
this correct? Are there better links I should be using?
SQL2K SP3
TIA, ChrisR
You begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/de...us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>
|||Well, that is close, but not quite accurate.
Even on a stand-alone installation, when you run the setup dialogue in
interactive mode, all that really happens is that a custom .iss file is
generated from your responses to the questions. Once all of the information
is gathered, setup then executes the setupsql with the newly created
setup.iss file as a parameter.
A cluster install is similar, except the setup.iss is deployed to both
nodes. During the installation, the cluster fails the disk over to each
node so that the individual setup.iss files can be ran against two
independently executed setupsql commands. This creates registry keys.
However, since the first install already created the directory structure,
deployed the binaries, installed the .sql scripts to master, model, and
msdb, this part of the process does not run again a second time. Just the
registry keys, performance counters, and client side tools. And, of course,
the MDAC, which is client side and IS NOT cluster aware.
Also, there is such a thing as the "Primary Node." This is nothing more
than the node from which you started the installation. It does not matter
which node you begin the installation on, as long as it is the node that
currently owns the disk resource you plan on installing SQL Server to.
However, it is important that you keep in mind which node this was.
This node will be the only one that maintains a record of the setup logs.
There is also special CLSIDs that only this node will contain that will not
propagate to the other. The nodes are close to the same configuration, BUT
NOT EXACT. This will be important in the future when you try to add
additional disk resources or swap out old disks for new, if you ever need to
modify or add an additional IP resource, or change the domain the cluster
belongs to. Keeping in mind which node was PRIMARY will only be to your
benefit.
Sincerely,
Anthony Thomas

"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
You begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/de...us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>
|||I have had to change accounts and add/remove disk resources. As long as I
use the current owner node, everything works fine.
Yes, there are some subtle differences such as log files between nodes but
that is only relevant during installation failure troubleshooting. Once
everythign is running, there is no practical difference between nodes,
unlike SQL 7.0 clustering.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OfrkU8e$EHA.1084@.tk2msftngp13.phx.gbl...
> Well, that is close, but not quite accurate.
> Even on a stand-alone installation, when you run the setup dialogue in
> interactive mode, all that really happens is that a custom .iss file is
> generated from your responses to the questions. Once all of the
information
> is gathered, setup then executes the setupsql with the newly created
> setup.iss file as a parameter.
> A cluster install is similar, except the setup.iss is deployed to both
> nodes. During the installation, the cluster fails the disk over to each
> node so that the individual setup.iss files can be ran against two
> independently executed setupsql commands. This creates registry keys.
> However, since the first install already created the directory structure,
> deployed the binaries, installed the .sql scripts to master, model, and
> msdb, this part of the process does not run again a second time. Just the
> registry keys, performance counters, and client side tools. And, of
course,
> the MDAC, which is client side and IS NOT cluster aware.
> Also, there is such a thing as the "Primary Node." This is nothing more
> than the node from which you started the installation. It does not matter
> which node you begin the installation on, as long as it is the node that
> currently owns the disk resource you plan on installing SQL Server to.
> However, it is important that you keep in mind which node this was.
> This node will be the only one that maintains a record of the setup logs.
> There is also special CLSIDs that only this node will contain that will
not
> propagate to the other. The nodes are close to the same configuration,
BUT
> NOT EXACT. This will be important in the future when you try to add
> additional disk resources or swap out old disks for new, if you ever need
to
> modify or add an additional IP resource, or change the domain the cluster
> belongs to. Keeping in mind which node was PRIMARY will only be to your
> benefit.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
> You begin the installation from the node that currently owns the disk
> resource you want SQL data files installed to. You can add additional
disk
> resources after the installation. The SQL installer adds code
automagically
> to the nodes you specify, provided they actually exist and are running at
> install time. You can add or remove nodes from the SQL installation later
> if you need to. Once SQL is installed, there is no difference between
> installed nodes except for which one is actually running SQL at a given
> moment.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
>
http://msdn.microsoft.com/library/de...us/howtosql/ht[vbcol=seagreen]
to[vbcol=seagreen]
boxes?
> Is
>

Cluster setup question

Im viewing the Cluster setup instructions at:
http://msdn.microsoft.com/library/d...-us/howtosql/ht
_clustering_51rm.asp
But it doesnt say where to install SQL. It seems to me that if I wanted to
have an Active/ Passive Cluster I would need to intsall it on both boxes? Is
this correct? Are there better links I should be using?
SQL2K SP3
TIA, ChrisRYou begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/d...-us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>|||Well, that is close, but not quite accurate.
Even on a stand-alone installation, when you run the setup dialogue in
interactive mode, all that really happens is that a custom .iss file is
generated from your responses to the questions. Once all of the information
is gathered, setup then executes the setupsql with the newly created
setup.iss file as a parameter.
A cluster install is similar, except the setup.iss is deployed to both
nodes. During the installation, the cluster fails the disk over to each
node so that the individual setup.iss files can be ran against two
independently executed setupsql commands. This creates registry keys.
However, since the first install already created the directory structure,
deployed the binaries, installed the .sql scripts to master, model, and
msdb, this part of the process does not run again a second time. Just the
registry keys, performance counters, and client side tools. And, of course,
the MDAC, which is client side and IS NOT cluster aware.
Also, there is such a thing as the "Primary Node." This is nothing more
than the node from which you started the installation. It does not matter
which node you begin the installation on, as long as it is the node that
currently owns the disk resource you plan on installing SQL Server to.
However, it is important that you keep in mind which node this was.
This node will be the only one that maintains a record of the setup logs.
There is also special CLSIDs that only this node will contain that will not
propagate to the other. The nodes are close to the same configuration, BUT
NOT EXACT. This will be important in the future when you try to add
additional disk resources or swap out old disks for new, if you ever need to
modify or add an additional IP resource, or change the domain the cluster
belongs to. Keeping in mind which node was PRIMARY will only be to your
benefit.
Sincerely,
Anthony Thomas
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
You begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/d...-us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>|||I have had to change accounts and add/remove disk resources. As long as I
use the current owner node, everything works fine.
Yes, there are some subtle differences such as log files between nodes but
that is only relevant during installation failure troubleshooting. Once
everythign is running, there is no practical difference between nodes,
unlike SQL 7.0 clustering.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OfrkU8e$EHA.1084@.tk2msftngp13.phx.gbl...
> Well, that is close, but not quite accurate.
> Even on a stand-alone installation, when you run the setup dialogue in
> interactive mode, all that really happens is that a custom .iss file is
> generated from your responses to the questions. Once all of the
information
> is gathered, setup then executes the setupsql with the newly created
> setup.iss file as a parameter.
> A cluster install is similar, except the setup.iss is deployed to both
> nodes. During the installation, the cluster fails the disk over to each
> node so that the individual setup.iss files can be ran against two
> independently executed setupsql commands. This creates registry keys.
> However, since the first install already created the directory structure,
> deployed the binaries, installed the .sql scripts to master, model, and
> msdb, this part of the process does not run again a second time. Just the
> registry keys, performance counters, and client side tools. And, of
course,
> the MDAC, which is client side and IS NOT cluster aware.
> Also, there is such a thing as the "Primary Node." This is nothing more
> than the node from which you started the installation. It does not matter
> which node you begin the installation on, as long as it is the node that
> currently owns the disk resource you plan on installing SQL Server to.
> However, it is important that you keep in mind which node this was.
> This node will be the only one that maintains a record of the setup logs.
> There is also special CLSIDs that only this node will contain that will
not
> propagate to the other. The nodes are close to the same configuration,
BUT
> NOT EXACT. This will be important in the future when you try to add
> additional disk resources or swap out old disks for new, if you ever need
to
> modify or add an additional IP resource, or change the domain the cluster
> belongs to. Keeping in mind which node was PRIMARY will only be to your
> benefit.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
> You begin the installation from the node that currently owns the disk
> resource you want SQL data files installed to. You can add additional
disk
> resources after the installation. The SQL installer adds code
automagically
> to the nodes you specify, provided they actually exist and are running at
> install time. You can add or remove nodes from the SQL installation later
> if you need to. Once SQL is installed, there is no difference between
> installed nodes except for which one is actually running SQL at a given
> moment.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
>
http://msdn.microsoft.com/library/d...-us/howtosql/ht
to[vbcol=seagreen]
boxes?[vbcol=seagreen]
> Is
>

Thursday, March 8, 2012

CLR procedure implementation

hi,

i have created a class library to validate the pattern of regular expression.

now how do i call it in an t-sql program so that the class library will read data from database and return the appropriate value?

i am trying to integrate the clr procedure.. but somehow i aint confident, about passing the parameters,

chaman!

Hi,

there are several samples out there:

http://msdn2.microsoft.com/en-us/library/ms131094.aspx (in this case with an additional output parameter)

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

Wednesday, March 7, 2012

CLR Assembly redeploy problem.

I have created a C# library containing CLR stored procedures and user-
define functions using Visual Studio 2005, and I have used Visual
Studio to deploy the assembly to a SQL Server 2005 instance
successfully, of course these sps and udfs are used by other T-SQL sps
and udfs. Now the assembly has a new version, and I want to use it to
replace the original one, but when I use Visual Studio 2005 to deploy
the new assembly, the following error occurs:

Error1Cannot drop the function 'TranslationStringLike', because it
does not exist or you do not have permission.
Cannot drop the function 'TranslateEngString', because it does not
exist or you do not have permission.
Cannot drop the function 'TranslateEngStringReverse', because it does
not exist or you do not have permission.
DROP ASSEMBLY failed because 'FirmBankCLR' is referenced by object
'TranslationStringLike'.FirmBankCLR

That is the assembly is dependent by other objects, it can't be
dropped until it is not dependent by other objects. How can I resolve
this problem using Visual Studio 2005 or something else?Amber (guxiaobo1982@.gmail.com) writes:

Quote:

Originally Posted by

I have created a C# library containing CLR stored procedures and user-
define functions using Visual Studio 2005, and I have used Visual
Studio to deploy the assembly to a SQL Server 2005 instance
successfully, of course these sps and udfs are used by other T-SQL sps
and udfs. Now the assembly has a new version, and I want to use it to
replace the original one, but when I use Visual Studio 2005 to deploy
the new assembly, the following error occurs:
>
Error 1 Cannot drop the function 'TranslationStringLike', because
it does not exist or you do not have permission. Cannot drop the
function 'TranslateEngString', because it does not exist or you do not
have permission. Cannot drop the function 'TranslateEngStringReverse',
because it does not exist or you do not have permission. DROP ASSEMBLY
failed because 'FirmBankCLR' is referenced by object
'TranslationStringLike'. FirmBankCLR
>
That is the assembly is dependent by other objects, it can't be
dropped until it is not dependent by other objects. How can I resolve
this problem using Visual Studio 2005 or something else?


As long as the interface of the assembly does not change, you can just
do ALTER ASSEMBLY. Either specify directly, which is simple if the DLL
is accessible from SQL Server. Or specify the DLL as a hexstring directly
in the ALTER ASSEMBLY statement.

If the interface has changed, you will need to drop all functions
created from it, as well as dependent assemblies.

I learnt just the other day that ALTER ASSEMBLY is not in the repetoir
of Visual Studio. I don't use Visual Studio to work with assemblies
but stick to the command line. And all impression I get is that
using Visual Studio just makes things harder.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||

Quote:

Originally Posted by

I learnt just the other day that ALTER ASSEMBLY is not in the repetoir
of Visual Studio. I don't use Visual Studio to work with assemblies
but stick to the command line. And all impression I get is that
using Visual Studio just makes things harder.


It seems Microsoft hasn't done the job well, but if we have a lot of
objects in the assembly, the manual process of dropping and creating
them is horrible.|||Amber (guxiaobo1982@.gmail.com) writes:

Quote:

Originally Posted by

Quote:

Originally Posted by

>I learnt just the other day that ALTER ASSEMBLY is not in the repetoir
>of Visual Studio. I don't use Visual Studio to work with assemblies
>but stick to the command line. And all impression I get is that
>using Visual Studio just makes things harder.


>
It seems Microsoft hasn't done the job well, but if we have a lot of
objects in the assembly, the manual process of dropping and creating
them is horrible.


Yes, it's horrible if you have to do it each time you change the
implementation of some single method, and it's amazing that VS cannot
handle this situation.

If you change the interface, it's still a lot of work of course of dropping
and recreating objects. But it is or more less inevitable.

I don't know what's in your assemblies, but I woudl suggest that if you
have a suite of functions and procedures that are independent of each other,
that it's best to have a separate assembly for each function/procedure. Of
course, if they use a lot of common code, you still need to put that common
code in a single assembly in which case you are back to the same situation.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Saturday, February 25, 2012

client-side SQLXML

I assume from http://technet.microsoft.com/en-us/library/ms171948.aspx
that it is possible to have the server-side provider be an OLEDB provider
for Oracle
for instance. But I have failed to find any code samples where SQLXML is
used
client-side to query Oracle or any other RDBMS. Does anyone have an example
of this?
Thanks,
Chris
Chris Harrington
Active Interface, LLC.
http://www.activeinterface.com
The client side SQLXML is only built into the SQL Server OLEDB provider so
it won't work against anything except SQL Server.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"ChrisHarrington" <charrington-at-activeinterface.com> wrote in message
news:erR04RBwHHA.736@.TK2MSFTNGP06.phx.gbl...
>I assume from http://technet.microsoft.com/en-us/library/ms171948.aspx
> that it is possible to have the server-side provider be an OLEDB provider
> for Oracle
> for instance. But I have failed to find any code samples where SQLXML is
> used
> client-side to query Oracle or any other RDBMS. Does anyone have an
> example of this?
> Thanks,
> Chris
>
> Chris Harrington
> Active Interface, LLC.
> http://www.activeinterface.com
>
|||But the diagram clearly shows SQLXML being used with "other dbms" systems -
did MSFT make an untrue statement with that diagram?
"Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
news:D40B1CAA-9270-4E94-A151-E14027811B8E@.microsoft.com...
> The client side SQLXML is only built into the SQL Server OLEDB provider so
> it won't work against anything except SQL Server.
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
> "ChrisHarrington" <charrington-at-activeinterface.com> wrote in message
> news:erR04RBwHHA.736@.TK2MSFTNGP06.phx.gbl...
>
|||Sorry, my bad. We used to block that. I assume you just have to specify
the right OLEDB connection string for your provided. Other than that there
shouldn't be any difference.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"ChrisHarrington" <charrington-at-activeinterface.com> wrote in message
news:u6MdKJewHHA.4916@.TK2MSFTNGP04.phx.gbl...
> But the diagram clearly shows SQLXML being used with "other dbms"
> systems - did MSFT make an untrue statement with that diagram?
> "Roger Wolter[MSFT]" <rwolter@.online.microsoft.com> wrote in message
> news:D40B1CAA-9270-4E94-A151-E14027811B8E@.microsoft.com...
>

Thursday, February 16, 2012

Client Net Library Changes

I have been asked to consider changing the Net Library TCP/IP port for SQL
Server from the default 1433 to a different one.
The problem is the 1800 user stations.
Is there a scriptable way to change the port on the clients without having
to visit each one to do it manually?When you create an alias o the client (start->run->cliconfg.exe->alias tab)
- a registry key value with the alias properties will be created under:
HKLM\SW\Microsoft\MSSQLServer\Client\Con
nectTo . So you can write a script
to add this registry key value. If this a named instance then the clients
should be able to "dynamically" determine the port number and no registry
key modification should be necessary.
See the MSDN article : How To Use the Windows Script Host to Read, Write,
and Delete Registry Keys
for more details on how to write to the registry through script.
reference:
Books online topics:
- Client Network Utility
- Managing Clients
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx

Client Net Library Changes

I have been asked to consider changing the Net Library TCP/IP port for SQL
Server from the default 1433 to a different one.
The problem is the 1800 user stations.
Is there a scriptable way to change the port on the clients without having
to visit each one to do it manually?
When you create an alias o the client (start->run->cliconfg.exe->alias tab)
- a registry key value with the alias properties will be created under:
HKLM\SW\Microsoft\MSSQLServer\Client\ConnectTo . So you can write a script
to add this registry key value. If this a named instance then the clients
should be able to "dynamically" determine the port number and no registry
key modification should be necessary.
See the MSDN article : How To Use the Windows Script Host to Read, Write,
and Delete Registry Keys
for more details on how to write to the registry through script.
reference:
Books online topics:
- Client Network Utility
- Managing Clients
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx

Client Net Library Changes

I have been asked to consider changing the Net Library TCP/IP port for SQL
Server from the default 1433 to a different one.
The problem is the 1800 user stations.
Is there a scriptable way to change the port on the clients without having
to visit each one to do it manually?When you create an alias o the client (start->run->cliconfg.exe->alias tab)
- a registry key value with the alias properties will be created under:
HKLM\SW\Microsoft\MSSQLServer\Client\ConnectTo . So you can write a script
to add this registry key value. If this a named instance then the clients
should be able to "dynamically" determine the port number and no registry
key modification should be necessary.
See the MSDN article : How To Use the Windows Script Host to Read, Write,
and Delete Registry Keys
for more details on how to write to the registry through script.
reference:
Books online topics:
- Client Network Utility
- Managing Clients
Fany Vargas
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
Microsoft highly recommends that users with Internet access update their
Microsoft software to better protect against viruses and security
vulnerabilities. The easiest way to do this is to visit the following
websites:
http://www.microsoft.com/protect
http://www.microsoft.com/security/guidance/default.mspx