Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built 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 © 2017, 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 or appropriate markings.