Connect – a Simba Technologies Blog

Minding your bits...

I note that Window's transition from 32-bit to 64-bit has been an on-going saga for the last few years. The 64-bit variant of Windows XP was a big step forward. Another major milestone was just recently crossed when Microsoft released the first 64-bit variant of Microsoft Office as part of the Office 2010 launch in May.

For those who were around when Windows last made a machine-word-size transition--from 16 to 32-bit--things will be a deja vu of sorts.

I've noticed that this time around, everyone seems to be jumping onboard the biggest, baddest Excel (64-bit 2010) with a lot more enthuasism than I recall the last time around.

One impediment lurking in the background that many people may be caught off-guard by is the availability of the appropriate 64-bit database drivers/providers. Simba's been working hard to catch up here.

So what are people's experience with 64-bit Excel so far? How has your transition to 64-bit been? What sorts of difficulities have you ran into when you made the leap to 64-bit?

The case for a custom ODBC driver

I was talking to a customer recently and they were telling me they have a very high performance database that scales very well, but they have poor reporting.  They were complaining that they spent so much time on building such a great database product and all their customers see is that they cannot get the reports they need.  So what to do?

The answer is simple, build a custom ODBC driver for the database.  The database product already supports SQL so all they need is ODBC.  The customer complained that they didn't have anyone in the company who understands ODBC.  Again, the answer is simple.  I asked one of our engineers to work with the customer and they literally had Crystal Reports talking to their database using the custom ODBC driver in about a week.  The customer was amazed.  They went to one of their users and gave them a demo of the proof of concept ODBC driver.  The user loved it.  Our customer was ecstatic because they now had access to all ODBC compliant applications to show off their database.  Win-win-win.

EMC buys GreenPlum

Interesting news yesterday about EMC's acquisition of data warehouse appliance company GreenPlum.  GreenPlum had of course partnered heavily with Sun Microsystems which was recently acquired by database giant Oracle.  GreenPlum has some interesting customers including eBay, NYSE Euronext, and NASDAQ OMX Group.  GreenPlum plays in the same space as veterans Teradata and Oracle and upcomers like Aster Data, Kognitio, ParAccel, InfoBright, Vertica, etc.  This is a very interesting space which saw Microsoft acquire DataAllegro and coming out with SQL Server 2008 R2 Parallel Edition as well as SAP's pending acquisition of Sybase.  SAP is also working on their own in-memory column-oriented technology and their upcoming HANA appliance.  As the volume of data continues to grow exponentially, the ability to store and analyze large amounts of data continues to be a challenge for every enterprise and so we will continue to see more action in this space.  As the databases scale to be larger and larger, one question that always comes up is how do we access and analyze all of this data.  The SQL query language accessed via ODBC and JDBC drivers continues to be the language of choice in the database world.  The MDX query language accessed via ODBO and XMLA is now the de-facto language of choice for analytics.

I was recently asked who supports MDX and the answer is, everyone.  The major database players - Oracle, IBM, Microsoft, and SAP all support MDX query language.  The major BI players - SAP/Business Objects, Microsoft, Oracle/Hyperion, and IBM/Cognos all support the MDX language.  Microsoft Excel is on virtually every desktop in the enterprise and if you look at Microsoft's recently released Excel 2010, the BI capabilities in Pivot Tables has been extended with the addition of sparklines, slicers, and even write-back.  Excel Pivot Tables talks to analytic databases using the MDX query language.  SQL and MDX are both necessary for analytics today.

The Kingdom of Excel

Whoa!  At the Gartner BI Summit, they suggested we "Wave the white flag on using Excel for business intelligence".  What breakthrough thinking!  This is something we at Simba have seen for years.  Many BI/OLAP vendors have come to us looking for an MDX Query Language solution for their OLAP/data warehousing products. We have found that a key driver for supporting the MDX Query Language was connectivity with Excel and specifically Excel Pivot Tables.  Microsoft continues to invest heavily in the BI capabilities of Excel and having an MDX Provider for your OLAP/multi-dimensional data source allows Excel to connect natively.  Native Excel connectivity is something we have now brought to Oracle OLAP cubes and we will even be at the Oracle Collaborate 10 conference next week where we have two sessions on showing users how to use Excel to connect to Oracle 11g database: http://www.simba.com/news/Simba-Provides-Free-Training-Connecting-Excel-PivotTables-to-Oracle-OLAP-at-COLLABORATE.htm.

Excel connectivity is a very important feature of any data source be it relational, multi-dimensional, ISAM, object-oriented, XML, etc.  Excel can connect to anything that has an ODBC or an ODBO interface.  Once someone can see how their data can be pulled live into Excel and how an Excel user can then get creative in their tool of choice, it becomes a very powerful reason to have an ODBC driver or ODBO provider.

You can read more about what Gartner is saying here: http://searchbusinessanalytics.techtarget.com/news/2240018042/Gartner-BI-Summit-Wave-the-white-flag-on-using-Excel-for-business-intelligence.

The new efficiency/normal according to Steve Ballmer

I was reading Steve Ballmer's latest email entitled "The New Efficiency" (http://www.microsoft.com/mscorp/execmail/2009/09-29NewEfficiency.mspx) in which he basically says the new normal in business is that "people borrow less, save more, and spend with much greater caution."  This is a simple yet powerful premise to do more with less.  At Simba, we have always tried to help our customers do more with less.  Simba started out helping ISVs deliver custom ODBC and JDBC drivers to their customers to increase value.  With our ODBC and JDBC SDKs, our ISV customers were able to quickly and efficiently build open standards based data connectivity for their databases which then gave their customers tremendous advantage in they could now use a wide variety of applications with these databases.  Then, Simba broadened what we did by also adding an OLAP SDK that supports ODBO and XMLA.  Today, Simba is going a step further.  We are now adding value directly for enterprise customers.  Our new MDX Provider for Oracle OLAP lets any user of Oracle OLAP connect to their data directly from Microsoft Excel.  The user gets to leverage all the power of Excel and Oracle OLAP without having to either use an Excel spreadsheet add-in which requires learning new software or a separate mid-tier server which can be quite expensive and take time to install and configure.

ODBC 3.80 is here!

Finally, ODBC 3.80 is here!  According to Pak-Ming Cheung from Microsoft, “We’re excited to announce that version 3.8 of the Microsoft ODBC DM (Driver Manager) will be released in Windows 7 and Windows Server 2008 R2”.  You can read more in his blog post at: http://blogs.msdn.com/data/archive/2009/07/06/odbc-dm-3-80-in-windows-7-and-windows-server-2008-r2.aspx.

 

Basically, there are 4 main new features in ODBC 3.80:

1.       Streamed Output Parameters

2.       ODBC C-Type Extensibility

3.       Asynchronous Connection Operation

4.       Better Management in ODBC Connection Pooling

 

As a leader in the data connectivity space in general and ODBC in particular, Simba is definitely committed to supporting ODBC 3.80.  If you would like more information, please don’t hesitate to contact us to discuss further.

ODBC Driver for Microsoft HealthVault

At Simba, we have a SDK to build a custom ODBC driver.  We have been working with Microsoft HealthVault and decided to use our ODBC SDK to build a custom ODBC driver for Microsoft HealthVault using their webservice API.  For those of you who are not familiar with Microsoft HealthVault, it is a secure online storage for all of your healthcare data.  You can get more information here: http://www.healthvault.com.  This is a very cool concept to be able to store all of your healthcare information in the Cloud and have access to it from wherever you are.  You have total control and privacy and only people you authorize can view your data.

 

HealthVault has a nice webservice API for developers and it was pretty easy to take our ODBC SDK and build an ODBC driver for HealthVault - it took us around two weeks to build this driver.  We found there were a lot of very good use cases for the HealthVault ODBC driver. For example, consider a diabetic person.  This person can buy a blood glucose meter from various companies that will allow them to connect to HealthVault and upload their daily blood glucose levels http://www.healthvault.com/personal/devices.html?type=device. Then, this person can use the HealthVault ODBC driver to pull this information into Excel and chart the data so they can easily see how they are doing. Another example is an athlete who wants to track their heart rate and how much they are running. Again, there are devices that will track this information and allow easy uploads to HealthVault from where they can use the ODBC driver to pull data to Excel and easily track their progress.

 

Simba is supporting Microsoft HealthVault by allowing free usage of our HealthVault ODBC driver for personal use.  You can get more information or download the ODBC driver here: http://www.simba.com/ODBC-Driver-for-HealthVault.htm.

 

Since our ODBC SDK allows any software developer to easily build a custom ODBC and/or JDBC driver for any data source including ISAM, XML, object oriented, SCADA, or cloud data source, it was very easy for us to build the HealthVault ODBC driver.  If you can think of other things we could build an ODBC driver for, we would love to hear from you. (Especially, if you think it cannot be done)

ODBC 3.8

I wrote a while ago that ODBC continues to be a very important data connectivity interface: http://blogs.simba.com/simba_technologies_ceo_co/2007/11/odbc-rocks.html.  It has been over a decade since Microsoft last updated the ODBC specification and now with Windows 7, they are introducing ODBC 3.8.  There is a brief mention of it the the Microsoft SQL Server Native Client team blog: http://blogs.msdn.com/sqlnativeclient/archive/2009/01/17/odbc-3-8-is-in-beta-1-of-the-windows-7-sdk.aspx.  The main new features of ODBC 3.8 are: 

- executing connection operations asynchronously

- streamed output parameters

- ODBC C data type extensibility

 

These seem to be features driven by SQL Server but most interesting is that the good folks at Microsoft are continuing to invest in ODBC which continues to be the de-facto open standard for relational database connectivity.

ODBC Rocks

I read the article entitled “ODBC Rocks” on the CoDe Magazine website and I wanted to comment on it. The full article is at “http://www.code-magazine.com/article.aspx?quickid=990712172&page=1”. This is a very good article written by Chris Lee who is a Program Manager at Microsoft. Chris made some very good points:

1. "Fifteen years after its launch, ODBC is a firmly entrenched cornerstone of the software industry.”
2. "For the data source owner, ODBC is a must.”
3. "At the time of its release, the SQL Server team at Microsoft believed OLE DB would supersede ODBC. This is no longer the case and ODBC’s future is completely secure.”

If you read my blog post of September 24th, “http://blogs.simba.com/simba_technologies_ceo_co/odbc/index.html”, I discussed why an ISV would want to build an ODBC Driver. Chris says that “for the data source owner ODBC, is a must,” and I could not agree more. If you build an ODBC driver for whatever data source you have, the data source is now open to the widest set of applications possible. This is the biggest win for any data source owner.  The more applications that your data source is exposed to, the more valuable your data source.  The business case for an ODBC driver is irrefutable.

Why build an ODBC Driver?

I often get asked by people as to why you would want to build an ODBC Driver.  Usually the people asking work for ISVs (Independent Software Vendors) that have their own database and/or reporting application.

I usually provide the following example.

Consider an ISV that sells into the financial services sector and has been making great progress licensing its proprietary database and reporting application.  The ISV’s database is high performing and very scalable.  Likewise, it has a great reporting tool that allows the customer to do some fancy analytics on the data in the database.  Overall, the product’s code is well-developed and high quality.  Everything is very modular, and everything looks good.

However, the ISV’s CEO is reviewing business and finds that the company is making largely departmental sales and that most customers only have 5-10 users of its great system.  The CEO asks one of the company’s best customers – a major bank – why it is not deploying the product further than the 10 users it has.  The customer says that it loves the system, but its other departments that could use the system want to connect to it using Microsoft Excel and Business Objects Crystal Reports.  The problem is that data needs to be extracted from the system and then fed into Excel and Crystal through flat files.

This data connectivity problem is exactly what an ODBC Driver solves.  An ISV might have a great system, yet unless standard business query, reporting and analytical applications like Excel and Crystal can connect, the system will always only serve a niche role with data stored in the system that is trapped in a silo. 

Quite simply, an ODBC Driver allows a wide variety of applications to connect to a database through a standard interface and exposes the data to the maximum number of products and users.