Execute Sql Scripts on DB2

Whether you need to execute one Sql Script on a DB2 database or many Sql Scripts on one or many DB2 databases there is one solution unlike any other – Script Executor. Its simple and intuitive interface allows you to create deployment projects involving hundreds of scripts and hundreds of target databases and then with a click of a button execute them all based on the order you have determined and precedence constraints you may have set.

You can use Script Executor to execute scripts against DB2 9.0 databases.

You can read more and download your trial copy of Script Executor from: http://www.xsql.com/products/script_executor/

Script Executor now supports DB2 and SQL Server Compact

we just released a new version of Script Executor which now in addition of SQL Server 2008/2005/2000 and MySQL 5.0/5.1 also supports DB2 9.0 and SQL Server Compact Edition 3.5.

Script Executor provides for deploying Sql Scripts to multiple target databases with a click of a button and allows you to:

• organize target databases into logical groups
• organize your Sql Scripts into containers and order scripts within each container
• map script containers to database groups
• order mappings and set precedence constraints
• get a comprehensive execution report
• view execution results in one integrated easy to navigate interface

Download your trial copy today from: http://www.xsql.com/download/script_executor/

Independent consultants can quickly translate hours saved to dollars - employees can't

One would think (or at least I thought) that when it comes to selling auxiliary software tools it would be easier to sell them to an organization where the buyer is using the organization’s funds to purchase the product than to an independent consultant who has to shell out his own money. However having spent the last 5 years in the SQL tools market I have concluded that the opposite is true – generally speaking the independent consultants do not need much convincing, whereas the full time dba/developer in an organization seems to have a much harder time making a $300 decision!

So, that got me thinking: why would someone readily pay a few hundred dollars from his own pocket for one of our tools while a full time employee seems to struggle to make up his mind and appears to be constantly looking to come up with unusual scenarios that the off the shelf tool may not handle? I have come up with three main reasons (not necessarily an exhaustive list of reasons):

1. the value preposition for the independent consultant is very clear – every hour of their time has a price tag – if they find a tool that saves them 1 hour per day they can quickly translate that saved hour into dollars. On the other hand a full time employee can not easily convert “hours saved” to money, nor can his boss or the boss’ boss.
2. The bureaucracy that plagues many organizations significantly dilutes the short term value of such tools - if you as an employee are forced to go through hoops to get approval for purchasing a $300 product that will potentially save you a couple of hours per week then you may decide it is not worth the pain. The independent consultant on the other hand does not need to ask for permission from anyone so there are no “costs” associated with the approval process.
3. A programmers ego: “I can do this stuff myself, why should I pay someone else to do it for me” When it comes to productivity an independent consultant can not afford to have an ego whereas a full time employee can and furthermore, by building a custom solution instead of buying an off the shelf tool the full time programmer will likely consolidate his position with the company. A lot of you may be surprised but I have found that it is often easier to convince the higher ups to let you put 100 hours on a project than convince them to let you spend $300 on a tool.

Please note that this is not a “research based” conclusion – it is simply an opinion supported by personal experiences. Please feel free to add your perspective on this and don't forget to check out our tools - you don't even have to pay anything in some cases.

A real life Sql scripts deployment story

We got a surprise call today - a client that just purchased a license for the newly released Script Executor called to thank us (normally we thank our customers for choosing our products not the other way around)! He told us that for more than 2 years one of his most annoying weekly "chores" was to execute about 120 Sql scripts on a handful of SQL servers. The task was complicated by the dependencies between those Sql scripts - a set of scripts had to execute on Server 1 successfully before another set could be executed on Server 2 and so on. And of course within each set the scripts had to execute on a certain order. So every week he would consume many hours of his life opening and executing those 120 Sql scripts one after the other.

For the last few months he was using the free community edition of our Script Executor and it had helped him a lot but it wasn't exactly what he wanted whereas the new Script Executor 3 gave him exactly what he needed - he spent about 15 minutes configuring his Sql script deployment package and saved the project. Now, all he needs to do is click Execute and a task that once took hours takes him one minute to launch and about 10 - 15 minutes to review the results.

His words: "I would have gladly paid the $179 from my pocket if the company would not have approved the purchase. Thank you for an awesome product!"

Well, thank you! For us there is nothing better than knowing that our work is providing real value to others.

Execution order and precedence

In addition of allowing the user to organize Sql scripts in containers and ordering the scripts within each container the new Script Executor 3 allows the user to also order and set precedence constraints between “mappings”. In other words you may want scripts on the script container 1 to execute against the databases in the database group 1 first and only if those all succeed then execute the scripts in container 2 against database group 2 etc.

This cool feature allows the user to configure highly complex deployment scenarios involving dependencies between scripts and groups of scripts. The picture below shows where the Execution order and precedence constraint can be set for a given mapping.