jwcolby
jwcolby at colbyconsulting.com
Sat Nov 21 13:30:39 CST 2009
There is no "customer PC". This is my server in my office, running an application I will write, which I will operate. John W. Colby www.ColbyConsulting.com Shamil Salakhetdinov wrote: > 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 > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > >