Generic SQL c++ class for client/server
Posted in 1996
Topics: Connectivity: ODBC / JDBC / .NET, Platform-Specific Issues, Third-Party Tools & Monitoring
Hi Everybody A. I have developed a SQL client/server protocol for our own particular application which I would like to expand and this is just to throw an idea out here to see if it has any merits. I am going to do it anyway and if I can get more people hooked to the idea maybe we can pool our resources and accelerate my/our development. What I am doing is something like OBDC but at a more abstract level. B. In windows I have defined a class that works as follow OpenDatabase("xyz"); SQLStatement Query("SELECT name,surname FROM users_def "); if (Query.GetStatus() == 0) { char UserName[]; char SurName[]; while ( Query.Fetch() == 0 ) { strcpy (UserName, Query[0]->data); strcpy (SurName, Query[1]->data); } } CloseDatabase(); C. I can also get the datatype and size for each element. It also supports "other" types of sql statements like insert update delete etc. Using Winsock, I translate each each class member into string transmit the string to a server and wait for a reply. When the reply comes back it updates the data values in the client and you can access the results. D. Once you have implemented the class on a particular platform/database combination it may be used as 1. A class on the standalone machine for local applications. 2. Combine the class with socket 's to create a server to make the data accessable to client programs. E. Environments that I have used the model in. SERVER Informix SE on AIX. Windows 3.1 using Informix 4.10 CLIENTS 16 bit Windows using winsock (Runs under 3.1, 95 and NT) Linex using normal sockets. We have had acceptable response times dialing in through an Internet Service provider in Grand Rapids Michigan talking via the Internet to one of our clients's IBM AIX sitting in Huntsville,Al. F. ADVANTAGES for such an implementation. 1. Abstraction above the database level makes my code portable to any platform. This is a general advantage not necessary Client Server. I can switch database vendors much more easily. 2. In windows I have placed all these functions in a DLL. By replacing the DLL I can change my product betweeen * Standalone * Client/ Server * Any database I choose 3. I don't have to recompile my application code to do the things in 2 4. The code is true client/server - I just have to change the IP address to whom I am connecting to and I talk to the machine. I don't know what OS is on that machine is and I don't know the type of database I am connecting to. 5. I can give my clients the oppertunity to choose their own database system that falls within their budget and price range. 6. If such a project gets enough support I don't have to buy a development environment for every database package on the market and I can't be held hostage by a particular database vendor's inability to produce the goods. G. DISADVANTAGES 1. I work on my own and I don't have the time to port it to all operating platforms/ databases. My budget are limited and I dont have the resources to buy all the nice stuff available from vendors. 2. I am (currently) not using the asynchronous winsock implementation. It means the system waits until the server transmits an answer back. The response times are still more than acceptable. 3. I try and keep my database queries in my code simple so it will work with all database implementations. I don't know to what level one can push such a mechanism. 4. I am probably duplicating the stuff in OBDC but I talk to the database directly without any overhead - there are no overhead. I don't think you can make it much faster. (I dont know much about ODBC anyhow) 5. The model is very simple but that could be an advantage as well. 6. I work in c c++ and not all the people in the world are real programmers. H. My code are not really ready for scrutiny by outside parties (I'm the boss that checks comments) but if there are other people interested in cooperating in such a project I can work on it. (The client/server string encapsulation is Informix specific but that can be easily changed.) I am so confused by all the vendor claims, different names, models and products that making a decision on a database and interfacing it with my code are extremely complicated. The questions that needs to be answered are the following a. Am I barking up the wrong tree and reinventing the wheel. b. Are there ather developers that would be interested in cooperating and expanding the model. c. Should one draw up a formal spec for it and RFC it. d. What are the functionality that one should put in it to make it transportable to most databases. (Keeping it simple and not trying to bloat it with features somthing like SMTP) d. I am hoping that one could put something like this in the public domain. Any comments are welcome - Remember my first priority is to get my product out of the door and this would be a "Nice to have". I am also doing this to try and accelerate my own development for my customers sake. There has gone a lot of my resources into this and I havent made my first million yet - still just barely making a living so I'm not inclined to give anything away for free - yet. Note: My socket's stuff follows the same type of guidelines so I could probably draw up another thing like this just for the socket communication but my socket programming is not as hot is I would like to have it - If I only had time (and money) !!!! Gert Wallis (gertw@iserv.net) Snr Software Engineer Corporate Information Systems. Gert Wallis,CIS, email:gertw@iserv.net, tel: USA (616) 281-3337