With the Simba Technologies SimbaEngine SDK™, you can build your own custom OBDC, OLEDB, JDBC, or ADO.Net driver to connect your data source to any application, but did you know that you can create a driver that runs on a server with the switch of a configuration setting? Here’s how…
To begin, let’s look at what makes up a server that is built using the SimbaEngine SDK. A Simba based-server is a Data Store Interface (DSI) implementation that is running as its own application, accepting connections from ODBC, OLEDB, JDBC, or ADO.NET clients provided by Simba. There are benefits to using a server. For example, you can have your implementation located as close as possible to your data source, leading to faster processing and less transmission of data to client drivers. In addition, when you use a server instead of a standalone driver you get the benefit of using Simba’s own ODBC, JDBC, and ADO.NET clients to connect to your data source. The Simba clients are optimized by our team of expert engineers to provide you with the ease of use and performance you need to connect your data source to any application. The only work you have to do is implement and maintain your DSI implementation while we take care of the communication between your server driver and our clients. Also, when you want to update your DSII (DSI Implementation), you update it on the server instead of distributing an update to all of your clients.
- To build a server, you need a previously-implemented DSI to communicate with your data source and have it built and working as a single-tier ODBC driver. It is easier to debug a standalone DSII than a server DSII, which will reduce development time. To get started, use the Quickstart sample shipped in the SimbaEngine SDK.
- When you have an implementation of you DSII you can build your server to run on Windows or Linux environments.For a Windows-based server, open your Visual Studio project and open the build configurations. There are build configurations that contain the word “Server.” Those configurations build your DSIIs a server in either debug or release modes, bound statically or dynamically. Each of these configurations will build the driver as an executable rather than the standard DLL file, although you can also build your server as a DLL and have it act as a slave to another process.For a Linux-based server, just add BUILDSERVER=exe to the command line when building your driver from the standard makefiles.
- Once you have the server built you can move on to configuring the server. Windows server settings are stored in the registry, and Linux server settings are stored in an INI file. The location of these settings is dependent on what you have defined in your DSII for Windows or Linux branding. In our Quickstart driver, the location of these settings will be under HKLM\SOFTWARE\Simba\Quickstart\Server for Windows and simbaserver.quickstart.ini for Linux. Note that, for Windows, the branding is simply the part between HKLM\SOFTWARE\ and \Server:
For the Quickstart sample, we provide example configurations in the form of .reg files for Windows and .ini files for Linux to help get you started. You can edit these files and use them for your own server configuration. The settings are organized in a section called “Server” with multiple subsections for specific server settings. The subsections are Network, Admin, Buffer, and Threads, with each having some configuration settings available for you to customize. The main settings you need to change are the ErrorMessagesPath under the Server subsection, which controls the path the error messages are located in, and the ListenPort, under the Network subsection, which controls the port the server listens for client connections on. For more information regarding our Server configuration setting, please refer to SimbaClient/Server User Guide. Once you’ve finished the configuration, you can launch the executable and connect to the server using one of the provided clients.
- To connect to your new Simba-based server, the clients must match the port you defined in your server settings. The clients can also provide other settings that are specific to the data source such as user authentication, just like your stand-alone driver. Any setting that is not picked up by the server is passed directly to your DSI implementation.
Congratulations! You’ve built your stand-alone ODBC driver as a complete server with the switch of a configuration.