jwcolby
jwcolby at colbyconsulting.com
Fri Nov 20 20:05:57 CST 2009
That is used for manipulating the SMO object and SQL Server.
I am just learning this stuff and do what the demos tell me to do.
John W. Colby
www.ColbyConsulting.com
Shamil Salakhetdinov wrote:
> Hi John,
>
> By Microsoft.SQLServer.* I mean all the namespaces you mentioned
>
>> Microsoft.SQLServer.SMO
>> Microsoft.SQLServer.SMOEnum
>> Microsoft.SQLServer.SQLEnum
>> Microsoft.SQLServer.ConnectionInfo
>
> As well as their classes and those classes enumerations, methods,
> properties, events etc.
>
> <<<
> I do have multiple servers running SQL Server.
> The default is Azul but I may need to reference
> Stonehenge.
> But do you need to change the reference(/connection string information) to
> SQL Server after you have your program started?
> Do you need to enumerate SQL Server objects to solve your customers' tasks?
> Or maybe you have developed a kind of code generator, which does need to
> enumerate MS SQL Server objects and some of their properties to generate
> some custom code? - I can understand the latter - if you have to develop a
> lot of repetitive custom code then it's often useful to generate it...
>
> Thank you.
>
> --
> Shamil
>
>
> -----Original Message-----
> From: dba-vb-bounces at databaseadvisors.com
> [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Friday, November 20, 2009 11:31 PM
> To: Discussion concerning Visual Basic and related programming issues.
> Subject: Re: [dba-VB] SMO was Projects vs Solutions
>
> I don't understand the question.
>
> What do you mean by Microsoft.SQLServer.*
>
> I do have multiple servers running SQL Server. The default is Azul but I
> may need to reference
> Stonehenge.
>
> John W. Colby
> www.ColbyConsulting.com
>
>
> Shamil Salakhetdinov wrote:
>> Hi John --
>>
>> I'm wondering what's the use of that Microsoft.SQLServer.* when you have
> to
>> have your customer tasks done first of all?
>> Why not just use (static) custom settings to point to different SQL
> servers
>> etc.?
>>
>> I suppose Microsoft.SQLServer.* is good for companies like
>> http://www.red-gate.com/ for them to develop their tools used worldwide,
> and
>> I wonder what customers' business tasks can be solved by using
>> Microsoft.SQLServer.* ?
>>
>> Thank you.
>>
>> --
>> Shamil
>>
>> -----Original Message-----
>> From: dba-vb-bounces at databaseadvisors.com
>> [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
>> Sent: Friday, November 20, 2009 6:36 PM
>> To: Discussion concerning Visual Basic and related programming issues.
>> Subject: [dba-VB] SMO was Projects vs Solutions
>>
>> The object I am referring to is the SMO or SQL Server Management object.
> In
>> order to use it you
>> have to add several references:
>>
>> Microsoft.SQLServer.SMO
>> Microsoft.SQLServer.SMOEnum
>> Microsoft.SQLServer.SQLEnum
>> Microsoft.SQLServer.ConnectionInfo
>>
>> then in the classes using the SMO you have to do
>>
>> using Microsoft.SqlServer.Management.Smo;
>>
>> After that you can do things like:
>>
>> Server Svr;
>> Svr = new Server("MyServerName")
>>
>> foreach (Database in Svr.Databases)
>> {
>> //Etc.
>> //
>> }
>>
>> This allows you to iterate collections of database objects, using them
>> directly or just pulling the
>> names out (as I did) to populate lists, combos, collections etc.
>>
>> As I mentioned, once you have a database object you can manipulate it. I
> am
>> just starting to learn
>> what I can do with this API but it looks pretty powerful.
>>
>> John W. Colby
>> www.ColbyConsulting.com
>>
>>
>> jwcolby wrote:
>>> The blind leading the blind here.
>>>
>>> 1) I built a main application
>>> 2) I referenced the existing file repair applet from the main application
>> (project).
>>> 3) I set a using statement. It appears that you have to both reference
> it
>> and then use the "using"
>>> statement.
>>> 4) I can now open forms out in the file repair applet from the main
>> application.
>>> 5) I physically moved the file repair applet underneath the main
>> application directory.
>>> 6) I changed the directory for the applet and it just worked. That was
>> fairly easy.
>>> From this point on I "Add Project" to the main solution. I have added a
>> class project to wrap the
>>> DMO. In case you haven't discovered it, the DMO is a real cool SQL
> Server
>> Management Object API
>>> that allows you to see and manage database objects. I am just getting
>> into it but it allows me to
>>> reference a server object, then see the database collection. The each
>> database object has a table
>>> collection, the table object has a fields collection etc. Everything you
>> can see and manage in the
>>> SQL Server management studio you can (apparently) see and manage from the
>> SMO from C#.
>>> An example of what this does for me is allows me to see all of the
>> databases in a server, and thus
>>> populate a combo with their names. Selecting a database from the combo I
>> can see and fill a combo
>>> with the names of the tables. Selecting a database and a specific table
> I
>> can then can then run my
>>> stored procedures that export that table in that database to CSV files.
>>>
>>> That kind of stuff is what I do a lot of and what the big application
> will
>> manage.
>>> John W. Colby
>>> www.ColbyConsulting.com
>> _______________________________________________
>> dba-VB mailing list
>> dba-VB at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/dba-vb
>> http://www.databaseadvisors.com
>>
>>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature
> database 4625 (20091120) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.esetnod32.ru
>
>
> _______________________________________________
> dba-VB mailing list
> dba-VB at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-vb
> http://www.databaseadvisors.com
>
>