January 28, 2002 at 2:36 pm
I have just 'inherited' an inhouse app which uses DMO to maintain metadata info & recreate scripts etc. I need to rewrite a lot of the functionality to bring it up to speed with the project. Can anyone tell me the advantages of using DMO for these tasks over ADO?
Thanks
January 29, 2002 at 12:22 pm
Andy is away and I'm sure he has some. One nice thing is that in DMO there are methods to accomplish many tasks. In ADO you will have to code everything manually.
Steve Jones
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
February 2, 2002 at 6:20 pm
Steve is right on the money. Scripting is a great example of something that DMO does far better than you ever could with ADO.
7DMO is an object model just like you'd find in Word or Excel. While you could use ADO to connect to Excel to manipulate the data, you lose the richness of the Excel model itself. Use DMO to manage SQL, not for running anything besides the most basic query. The nice thing about DMO is if you have a developer who understands object models they can get up to speed in a very short time.
Could you explain further about why you need to rewrite it?
Andy
February 3, 2002 at 1:54 am
The generic subs and routines remain the same, but I have rewritten the bit to drop & recreate the audit triggers, as the triggers are now diferent. This app is now for a new project, and I have been asked to create routines and sub routines to upgrade from backend version x to y. As I have always just run incremental build scripts for this purpose, I feel that this is a bit of a sledegehammer to crack a nut.
February 3, 2002 at 8:11 am
If you're just applying minor changes to a db, I'd agree that a script is the way to go, especially since you still need to go through the process of testing the code on a test db first. Where DMO (along with VB or other language) shines is for tasks like creating audit triggers on all tables programmatically - essentially a cursor loop that is building the definitions on the fly. Great for a general purpose util.
So, I have two thoughts on your problem. One is that if something is basically working I prefer to leave it rather than rewrite to "my" standards - even if the app is not something I agree with in whatever way. Time is money. The other is (and Im sure you've checked) to make absolutely sure you understand why something was done a certain way before changing it. All this falls under the category of refactoring - done correctly can be great, done poorly leaves you spending a lot of time and/or rolling back to the previous version!
Andy
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply