Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
So you want to build an ODBC driver?
First, I want to say congratulations since this project reflects well on the popularity of your data source. As a Systems Engineer, I have worked with numerous shops on this project in each phase from planning, development, testing all the way to production; and I want to share the things that typically go overlooked.
This applies to all the common approaches including:
Building an ODBC driver is very much like the Harlem Shake. You build a single prototype and it seems to be doing ok, and then the base drops; and you have total chaos ranging from "our largest prospect cannot use open source driver managers on Linux" to "a request for a 64-bit AIX client the very next day for Informatica PowerCenter".
If you've never seen a Harlem Shake, our friends at Plex Systems produced one, along with great ODBC connectivity:
When you build a Unix/Linux ODBC client, there are a lot of things to consider upon releasing a driver:
ODBC has been around for decades and there are thousands of applications out there ranging from Microsoft Office and SQL Server to data visualization tools like Tableau, Qliktech or Spotfire. It's important to choose a codebase that has been battle tested. Here are some things to look out for:
For shops using a published protocol, you can own the end user experience by distributing commercial drivers such as the DataDirect Connect and Connect64 for ODBC Postgres drivers or the Hadoop Ecosystem.
As soon as you release an ODBC driver, I guarantee someone will ask for JDBC, OLEDB or ADO.NET that very same day. I am definitely hearing more about JDBC data integration tools such as Pentaho Data Integrator, Talend, and Oracle Data Integrator; as wells as Java web applications.
We do. And so do these guys: NetSuite, COINS Global, or Hewlett Packard.
Download a trial of the DataDirect OpenAccess SDK to address all the questions above, or call 1-800-876-3101 to speak live with an OpenAccess Systems Engineer to share your plans, and learn how other organizations are making progress with DataDirect OpenAccess when building drivers for a wide variety of data sources:
SaaS or On-premise Applications
File-based data stores
Sumit Sarkar is a Chief Data Evangelist at Progress, with over 10 years experience working in the data connectivity field. The world's leading consultant on open data standards connectivity with cloud data, Sumit's interests include performance tuning of the data access layer for which he has developed a patent pending technology for its analysis; business intelligence and data warehousing for SaaS platforms; and data connectivity for aPaaS environments, with a focus on standards such as ODBC, JDBC, ADO.NET and ODATA. He is an IBM Certified Consultant for IBM Cognos Business Intelligence and TDWI member. He has presented sessions on data connectivity at various conferences including Dreamforce, Oracle OpenWorld, Strata Hadoop, MongoDB World and SAP Analytics and Business Objects Conference, among many others.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.