Thursday, December 1, 2011

Enjoy a bundle of Smart SQL Solutions

I'm super excited to share our new product bundle, which is constantly growing.
SQL Stripes is now part of a bigger family --  The "Docco Labs" family!

The objective is always the same - to provide smart SQL solutions, making DBA's life easier and more productive.

Here's a quick recap for each product; (I will post more detailed looking into each and every one of them in the near future):

  • ClipTable
    • Make data import as easy as possible: Copy the desired data into your clipboard (yes, I mean Ctrl-C), and in a few seconds - have this data available in an SQL Table!
    • No more dealing with input drivers, delimiter settings, field size and type headaches.
  • Database File Explorer
    • Explore your Database files/filegroups size & table location in a very easy to understand UI
    • The hierarchy view will help you quickly understand what's stored where
  • Log Table Viewer
    • This is a complete SQL logging solutions - just use the server side procedure to write anything to the log, and then look at it with an amazing viewer, containing many kind of views, filters and more
  • SQL Stripes
    • Our 1st product, which is a complete monitor and control solutions for multiple server environment
The "Glue"
Although the 3 new products are seperate, there all use a "Shared Repository" (see screenshot), which means you only have to manage one server/group list, and quickly use any of the servers by any of the products

The new products are still in beta stage, this means they are free to use!
Give it a shot and tell us what you think -

Cheers :)

Tuesday, November 22, 2011 is up!

There are various great news coming in today!

First, We're happy to announce that is up and running.
Second, We're launching two new products (currently @ beta stages)
These products are the kickoff launch of our new path of extending our offered solutions.

So, what are those new products, you ask?

ClipTable -- 
A brand new way to import any data into SQL tables.
If you find yourself dealing with various SSMS wizards, trying to import those tricky Excel/CSV and other input files - ClipTable may be the best solution for you!
Out smart parsing engine reads any data you copy into your clipboard, and creates a table out of it.
Give it a shot - the beta is totally free!

Database File Explorer --
Our production databases usually have many files and filegroups.
Analyzing the locations, space consumption, hard-disk usage and more is usually a difficult task.
Out of the box Management Studio (SSMS) view is just a simple, unsorted, list of all files and filegroups.
So we usually find ourselves building various sys.* queries, into Excel and analyzing from there.
Well, no more!
We've created the perfect tool for such scenario, that gives you an extremely easy interface which helps you quickly understands the drive-space-file map each database is using.

Again, the beta is totally free, you're invited to give it a shot.


Tuesday, September 6, 2011

Continuous Integration on SQL Server

Yesterday, I gave a presentation at the “Israeli SQL Server User Group” (Part of PASS), discussing the importance of continuous integration, automatic build, and the approach of SQL Code handling in general.
Lecturing there was a pleasure, the audience was great and I’ve got many responses during, and after the presentation.

Presentation aside; what puzzles me the most, is the fact that many SQL Developers don’t treat their code the way other developers (c#, java etc...) do
SQL Code is not just ad-hoc scripts; the code is often part of a big enterprise system -
It has to connect altogether, to compile & build, to use the right references and to be clean and readable.
Keeping these guidelines, even before you implement Automatic builds / CI, help you be in control when a team of SQL developers rapidly write new code and modify existing one.

Another thing worth mentioning is – Automatic deployment in Visual Studio is by all means, not intended for production deployment.
The main concept is to keep an updated, high-quality development (and maybe QA) environments with the latest code. This will help us:
  •           Provide a ‘Latest’ database version for integration with the other dev teams
  •           Ensure code quality and stability

For production, use whatever you like (diff scripts, 3rd parties…)

"Bad Code"

Last but not least – I sensed some excitement around controlling the presentation with my tablet. I’m always happy to see that I’m not the only gadget freak in the room J
So, there are many solutions out there. I’ve used Unified Remote (for Android) along with the server-side installation
Control can be done either through Wi-Fi or BT 

get it here:

Tuesday, August 30, 2011

SQL Code refactoring

Code refactoring (wiki:  "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior") is a very common method of self-improving our existing code.

Doing this is extremely important and there are many resources, articles and forums discussing this topic.
Our SQL Code (procedures, functions etc…) is no different than any other regular code
And yet, we don’t see this common practice popular enough among SQL Developers.

It is important to distinct between query refactoring, which would usually aim at reformatting the query to better readability and in some cases – better performance, and actual code refactoring.

Frequently refactoring your code helps you make sure you (and other developers in your team) don’t get lost in long, spaghetti, unstructured code as your project grows.
In addition, you’ll be surprise of how much potential bugs you may find, fix and prevent during this process.

So, here are the common items you should be aiming towards:
-          Renaming (at least the internals that are not exposed to the outside application)
o   There are many tools, including Visual Studio, which will help you detect any rename any references to the renamed object. I strongly advise to use those
-          Keeping your procedures and functions small.
o   I personally saw too many of those 1000+ lines procedures. This is always a bad practice
o   And by the way, the solution is not to split a long procedure into [n] pieces J
-          Keeping the same structure/pattern. I’m referring to formatting, variable declaration, naming convention and more
-          Using schema prefix for different DALs. (this is a trick we’re using to divide the code into sub-systems)  For example:
o   Common.BatchDelete()
o   CallsDAL.StartTraceCall()
o   Etc…

Last but not least – during and after refactoring, always make sure that your project:
-          Compiles and builds with no errors
-          Deploys successfully
-          Passes all relevant unit-tests (to make sure backward compatibility and logic are not harmed)
 This is another big topic which I’ll cover in the near future.