Tuesday, May 28, 2013

New Releases!


I don't always blog about new versions, but today I do - because there are 3 new versions released today!

Here's what's new:
ClipTable:
- Repository instant groups by version has been fixed
- Advanced options now allow you to view ClipTable's main parsing engine messages
- UI enhancements
- v1.0.3.9 Released

Database File Explorer:
- Extended table properties: Estimated row size, index drill-down from column and more...
- On Database-based view, each drive (used by the database) will not also show the exact database size on that drive
- Better size unit display (kb/mb/gb/tb) - everywhere
- Animated indicator icon on TreeView when loading special analysis data
- Repository: Fixed some stability issues
- Repository: Fixed instant-grouping by version, added # of servers icon for each version
- UI enhancements
v1.0.3.0 released


Log Table Viewer
- Added support for auto server load (from repository)
- Server info changed to DoccoLabs standard server window
- Maximum log file size modified to 2mb
- Repository: Fixed instant-grouping by version, added # of servers icon for each version
v2.0.2.0 Released

Get it all here: http://www.doccolabs.com
If you already have it installed, you'll get a message allowing you to upgrade automatically.

Enjoy and as always - share your feedback.

Cheers,
Adi



Tuesday, May 21, 2013

What's taking my space?

Here is a common scenario I bet you've had - if you are, or were a Database Administrator;
You receive an alert, indicating that a certain drive (either storage or local) is running out of space.
And it's painted RED of course, to make sure you're not smiling!

If your alerting system is configured to give you some 'grace' time (i.e. 1% free space left), you have just a little time to figure out which databases/tables are taking that space.

In this post, I am going to show some samples from our Database File Explorer on how you can quickly troubleshoot such cases.
Big emphasis on the "some" - there is a full set of features not shown here.

So, let's begin on the main screen, showing me which drives are being used by my databases: (already letting you distinct between database space and other "stuff" on that hard drive)

Great! Now let's have a look on a graph showing me a pie slices for all databases.
Click on the Chart menu --


Choosing "Databases Size", and getting this:



OK. I can clearly see that there are two databases taking almost 100% of my disk space. Let's drill into one of them:


I've selected the 2nd largest database. If you look at the screenshot above you can see that it's using 2 drives (E:, F:)
Now note something interesting - When looking at the "Top 10 Tables by Size", I can quickly see that there is one table, taking 68% out of the entire database space.

I'm going to right-click the table and choose "Table Properties"



Getting a lot of useful information here, but something specific caught my eyes - note that this 85gb table is less than 20% data, and about 80% indexes!


 So the next step would be drilling into the indexes in order to figure our which indexes are consuming so much storage space.

I'm going to click on the "Chart" button below: 
And get this screen:


OK. See the last line on the graph legend? That's the "Data", and the rest is all index.

Going back to the previous window, I'm going to expend the "Indexes" node and get the list of all the indexes and their sizes/filegroups.


I've expended one of the indexes (taking almost 13gb) and saw it's built from multiple columns, where one (ApiKey) is indexed, while the rest are INCLUDED columns. This is a common problem, since included columns data is stored on the index leaf level. So while tempted to use for query performance reasons, including many fields - especially strings/blobs, will create huge indexes!

To sum things up - I've used Database File Explorer to quickly understand what's taking my disk space.
This is only a small part of what this app has to offer. (I will soon post a video showing a full demonstration of the product)
If you don't have it already, get it here:
http://doccolabs.com/products/dbfileexplorer


Wednesday, April 24, 2013

Table import - made even easier! Announcing Drag & Drop table importer.


Hi,
So as you probably already know, ClipTable's main concept is to copy any tabular text, from anywhere, into the clipboard and immediately turn it into a SQL Table.

Besides Clipboard data, ClipTable also supports direct-file import, accessible through the Import extra options (see screenshot):


And today, we're announcing a 3rd option, which speeds up the process even more -
The new version allows an easy Drag&Drop of any data into ClipTable, turning it into a SQL Table in no-time!
Here's how:

Run ClipTable, and choose the "Import Data" tab.
Now, select any tabular data from any source and drag it into ClipTable.
Here's the data we've used for sample:







Drag & Drop









That's it! the table is ready to be created on any of your databases.



Enjoy the new feature and as always - send us feedbacks.

And always remember -
ClipTable simplifies the way you import data from *any* source into your SQL Database.








Thursday, February 14, 2013

64-bit version for ClipTable is now available



For those of you working with 64-bit OS and would like to use the full cpu/memory power for ClipTable's heavy(er) actions - you're invited to try our new ClipTable x64.

We've come to realize that many of our users already use a 64-bit desktop environment, so while the regular 32-bit version works just fine.
ClipTable may require a lot of RAM when using large clipboard/file resources - hence the 64bit, letting you use all of your available system resources.

Get the new 64-bit version here:
http://www.doccolabs.com/products_cliptable.html


+SQL Server solutions by Docco Labs

Wednesday, October 24, 2012

How do you debug your stored procedures?

Well, perhaps 'Debugging' is not the best way to describe it. If you need to debug a procedure step-by-step, there are tools within SQL Server (or Visual Studio) that will, in most cases, allow you to do so.

But in real life (or let's just say - production), we often face a different situation where Stored-Procedures are being executed by the Application side (DAL's in most cases)
And sometimes, we don't just need to see which procedure was executed when (if we want to do this Profiler is there to help) - we need to track certain activities inside the stored procedures.

While application developers have a lot of logger libraries (such as Log4Net, for example), SQL Developers don't have an out-of-the-box solution.

So SQL Developers write their own solutions, and sometimes even use PRINT (god forbid!) within the procedures to track the output (yes, even today!)

This is why we've created Log Table Viewer.
The solution includes a simple table/procedure to write the log message (+severity and some other optional properties), and a client viewer to easily see and explore the written messages.

After deploying the solution (which is done automatically by the viewer app - by clicking this button):

you get a new procedure, which can be executed as simple as that:



EXEC usp_write_to_log @source='TestScript', @message='Hello World', @severity=1

What happens (by default) is this:
1:
You see an immediate output to the screen (if executed by SSMS) with the message
[Oct 24 2012  4:06:13:397AM] Hello World
The console does not use "PRINT" (which does not flush immediately into the screen), but rather a RAISERROR(@console_message,10,1) WITH NOWAIT statement, which is better in these cases

2:
A log message is written to our log table (tblLog)


There are many other option parameters when executing the procedures, here's the actually interface:
usp_write_to_log( 
 @source VARCHAR(255),
 @message VARCHAR(4192), -- 4k
 @severity INT = 1, /*0=Debug, 1=Informational, 2=Warning, 3=Critical*/
 @category INT = 1, /*1=Databases. For future use if more clients use this usp*/
 @write_to_console BIT = 1, /*New: Only write to console, not table*/
 @write_to_table BIT = 1, /*New: Only write to table not console */
 @write_to_sql_log BIT = 1, /*New: output to SQL errorlog as well (only for warning, error)*/
 @write_to_sql_log_minimum_severity INT = 3,
 @suppress BIT = 0 /*New emergency option; When compiled with (1) no actual writes to tblLog are made.*/
                           )


So now, you can easily use this procedure to write various messages inside your SQL Code.
Here's a screenshot for one of my servers, with some recent messages (just so you get the look & feel)
You can see the "Hello World" message we just wrote on the previous example:

Log Table Viewer - Real-time display


Tuesday, October 16, 2012

Triple release day!

3 Updates are being released today, for ClipTable, Database File-Explorer & Log-table Viewer

Here's the change-log:


ClipTable:
- BCP (insert) mode is now available! ClipTable can generate a BCP IN statement of any CSV file
- Added an option to turn any column into a string (after clipboard import is done)
- Data in grid can automatically extend on edit
- Better white-spaces handling on string analysis
- Improved XML detection
- SQL Text highlight feature implemented
- Multiple UI improvements
- v1.0.3.2 Released

Database File-Explorer:
- Log file is now being recycled when over a configured size (currently 10mb)
- Added ChangeLog (inside the About Window)
- Core classes updated
- SQL Text highlight feature implemented
- Shared Repository:
- Added SQL Profiler integration
- If multiple versions are installed, SSMS/Profiler will launch at the newest version
- Multiple UI improvements
v1.0.2.3 released


LogTableViewer:
- Main Engine updated
- SQL Text highlight feature implemented
- Multiple UI improvements
v2.0.1.6 Released


Shared Repository: (which means, all of the above)
   - Added SQL Profiler integration
   - If multiple versions are installed, SSMS/Profiler will launch at the newest version
   - Multiple UI improvements

Download all for free: 



Wednesday, October 3, 2012

(ClipTable) INSERT solutions

Hey ClipTable users!

As a user, you probably already know how ClipTable can quickly turn any data into a SQL Table.
The main-stream option would be:
- Copying a tabular data into your clipboard
- Pressing the magical "Import" button
- Defining a destination server
- Execute!

But there is more to it; Today I'm going to cover some other INSERT options ClipTable supports


For the demo I'm going to use a simple query against AdventureWorksLT2008:
select from AdventureWorksLT2008.SalesLT.CustomerAddress
I'm taking the result and saving it as a CSV file, and also copying the result into the clipboard.


The first one is the "Generate INSERT Statement" option; which, instead of pumping the data into the table, creates an insert script you can launch anywhere.
Here's how you use it:

Copying the above query data into the clipboard, I click "Import from Clipboard", and the query data now appears in ClipTable (see screenshot):





























Next, I'm going to jump right to the "Setup & Go" tab, but instead of clicking "Execute", I'm going to click the other part of the button, which contains additional insertion options (see screenshot):


Now, select the "Generate INSERT statements only", and the following window appears:

From this point, simply copy the data and execute anywhere you want.
Easy, isn't it?

Now let's move on to the other option: BULK INSERT.
On this option, you let ClipTable perform a field analysis on a CSV file, and then creating a complete BULK INSERT statement to load this file into a table, without having ClipTable to read the entire content into the memory first.
Needless to say, this feature is not 100% bullet-proof due to some known differences with BULK INSERT behavior  as well as the fact that the default option is to not analyzing to entire file (speed & memory considerations), so field types may need some additional tune-ups.

OK, Let's go back to the "Import Clipboard Data" tab, only this time, we'll select the "Import from File" option (see screenshot):


Now, let's choose the CSV we've prepared earlier.
Before doing so, as a preparation for the bulk insert, there are two options we're going to change:
1. Make sure "Treat NULL strings as DbNull" option is unchecked
2. Uncheck "Data contains Headers" (since the CSV file does not contain headers on the 1st line)
(see screenshot):

Now, let's jump to the "Setup & Go" tab again and choose the "Generate BULK INSERT" option.
The following window appears:

Again, you can now use this data from your Management Studio (or equivalent) in order to load the data into your table.


Ready to give it a shot?
Get the latest version (for free) here: http://www.doccolabs.com/products_cliptable.html

Cheers