[dba-VB] SMO was Projects vs Solutions

Hi John --

<<<
SMO appears to be similar to the DAO object 
where you can see and manipulate the table...
>>>
Yes, I understand/know that.

<<<
When I select the 
database that I want to export data from, I then 
use SMO (again a couple of more lines of code) to 
get a list of the tables in the selected database
and use that to populate a combo of tables.
>>>
Yes, but how often would you need to do that?
Why not just use (relatively static) program settings files, or utility
program execution command string parameters - I mean you anyway have to do
manual selection (in the case you'll use SMO) or manual editing and saving
(in the case you'll use program setting files...) - what for to spend time
on learning SMO if you very probably (am I wrong?) can solve your customer
tasks without using SMO, and applying relatively the same efforts in both
cases to implement custom logic (but in the case of using SMO you'll also
have to spend time on learning SMO)...

<<<
Given your persistent questioning of my motives 
I guess now I have to ask whether I am causing 
myself problems doing this?
>>>
Just maybe by spending time on learning SMO when you don't need it to
implement required custom logic?

Not sure (I didn't check so I can be wrong) but SMO might need special
installation procedures for customers' PCs without full MS SQL Version
(standard, prof., enterprise) so if you'll develop some custom code to be
reused on customers' PC then you might need to be prepared to develop custom
setup - not a big issue just be prepared - if I'm not wrong in guessing that
that custom setup would be needed for some customers system...

Thank you.

--
Shamil


-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Saturday, November 21, 2009 8:06 PM
To: Discussion concerning Visual Basic and related programming issues.
Subject: Re: [dba-VB] SMO was Projects vs Solutions

Shamil,

As far as I can tell they are quite different things, and perform different
jobs.  I do use 
SQLClient.  SQLClient appears to be about getting at data, and I do use that
for the ADO side of 
things.

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.aspx

SMO appears to be about getting at and manipulating the objects in the
database.

http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.a
spx

SMO appears to be similar to the DAO object where you can see and manipulate
the table (not the data 
IN the table) the fields, indexes and so forth.  It is a collection based
object where you can drill 
down into a server and see the objects underneath the database, then (for
example) drill down into a 
table and see the objects under the table.

Just as an example, using SMO in a few lines of code I got a list of all of
the databases in the 
database collection of my server.  I used that to populate a database combo
box.  When I select the 
database that I want to export data from, I then use SMO (again a couple of
more lines of code) to 
get a list of the tables in the selected database and use that to populate a
combo of tables.

I have no idea the relative merit of one way vs the other.  To me it is just
a tool.  In this 
particular case I use it to quickly and easily get at the names of objects
in the database.  I 
understand that using SMO you can do other maintenance kinds of things as
well.  One of the things I 
have to do is copy an "order template" database to a new name in preparing
to fill an order.  SMO 
appears to have built-in methods for doing this programmatically from C# -
as opposed to running 
TSQL or using some other method.

Understand I am not an expert on any of this, in fact quite the opposite.  I
stumbled across SMO and 
saw an example of how easy it was to get at the database STRUCTURE
information and decided to use it 
for that purpose, when I had that need.  Is there another way to do this?
Almost certainly, given 
that there is always a dozen ways to do anything in programming.

Given your persistent questioning of my motives I guess now I have to ask
whether I am causing 
myself problems doing this?

John W. Colby
www.ColbyConsulting.com


Shamil Salakhetdinov wrote:
> Hi John --
> 
> OK, but why not just use connections strings and System.Data.SqlClient
> classes, .... ?
> 
> Thank you.



 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4626 (20091120) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru