Re: SQL using C

user923005 wrote:
On Sep 6, 11:56 am, Tor Rustad <tor_rus...@xxxxxxxxxxx> wrote:
user923005 wrote:
On Sep 5, 8:19 am, MJK <jafari...@xxxxxxxxx> wrote:
Hello everybody,
I am almost a new C programmer and now I need to use SQL within my C
codes. Does anybody have any idea about good examples on SQL using C?
I have not any experience using SQL before.
The people who are telling you to use a C API are out of their mind.
What part of "new C programmer" and "not any experience using SQL"
didn't you understand? :)

None of it.

Agreed. :P

If MJK is playing around with the common LAMP stack (Linux + Apache +
MySQL + PHP), then the MySQL C API is a rather good option to get
started with minimum trouble, note that the C and PHP API's are very
similar.

This C API:
http://dev.mysql.com/doc/refman/5.0/en/c.html
is not less complicated than ODBC and ties the user to a single
vendor.

Getting started with MySQL C API require less fuzz, it works right out of the box, and perhaps even more important, lots of samle PHP code exist demonstrating usage of the API.


Going to another database will require a complete rewrite.

Why do you think this is relevant for a beginner?

When he has got everything up and running, he need to play around, get familiar with the SQL cmd-line interface, learn SQL, write some very simple C programs, and perhaps first use PHP as an easy entry to C programming.

Changing the DB server...will surely *not* be on his mind, for a rather long time!


Pulling in extra dependencies via e.g. ODBC, is a *really* bad advice
for beginners IMO.

Dependencies needed for ODBC:
1. ODBC lib
2. ODBC headers

Dependencies needed for Proprietary API:
1. Proprietary lib
2. Proprietary headers

If there is some clear improvement, I must have overlooked something.

ODBC will be designed *on top* of some proprietary API, as such this is an extra layer, which might introduce bugs, require extra installation and configuration.

Not long ago, I installed MySQL on a Windows box, now let us take a look:

C:\Programfiler\MySQL\MySQL Server 5.0\include>dir
[...]

28.08.2007 08:25 <DIR> .
28.08.2007 08:25 <DIR> ..
06.07.2007 13:24 13 170 config-win.h
06.07.2007 13:24 4 050 decimal.h
06.07.2007 13:24 3 866 errmsg.h
06.07.2007 13:24 6 729 keycache.h
06.07.2007 13:24 2 845 libmysql.def
06.07.2007 13:24 33 759 mysql.h
06.07.2007 13:24 17 026 mysqld_ername.h
06.07.2007 13:24 17 083 mysqld_error.h
06.07.2007 13:24 17 249 mysql_com.h
06.07.2007 13:24 1 175 mysql_embed.h
06.07.2007 13:24 2 097 mysql_time.h
06.07.2007 13:24 833 mysql_version.h
06.07.2007 13:24 1 810 my_alloc.h
06.07.2007 13:24 1 941 my_attribute.h
06.07.2007 13:24 3 872 my_dbug.h
06.07.2007 13:24 3 460 my_dir.h
06.07.2007 13:24 2 916 my_getopt.h
06.07.2007 13:24 43 277 my_global.h
06.07.2007 13:24 1 466 my_list.h
06.07.2007 13:24 3 853 my_net.h
06.07.2007 13:24 1 669 my_no_pthread.h
06.07.2007 13:24 27 965 my_pthread.h
06.07.2007 13:24 36 770 my_sys.h
06.07.2007 13:24 1 958 my_xml.h
06.07.2007 13:24 20 806 m_ctype.h
06.07.2007 13:24 8 120 m_string.h
06.07.2007 13:24 5 796 raid.h
06.07.2007 13:24 1 804 sql_common.h
06.07.2007 13:24 11 137 sql_state.h
06.07.2007 13:24 1 006 sslopt-case.h
06.07.2007 13:24 2 163 sslopt-longopts.h
06.07.2007 13:24 1 107 sslopt-vars.h
06.07.2007 13:24 1 300 typelib.h

the <mysql.h> is there, but where the heck is your ODBC header?!

Now, perhaps I have better luck on a Linux box, let see....

$ ls /usr/include/mysql
errmsg.h my_getopt.h mysqld_ername.h ndb
keycache.h my_global.h mysqld_error.h raid.h
m_ctype.h my_list.h mysql_embed.h sql_common.h
m_string.h my_net.h mysql.h sql_state.h
my_alloc.h my_no_pthread.h mysql_time.h sslopt-case.h
my_config.h my_pthread.h mysql_version.h sslopt-longopts.h
my_dbug.h my_semaphore.h my_sys.h sslopt-vars.h
my_dir.h mysql_com.h my_xml.h typelib.h

nooooooooooo!



AFAIK, the PHP ODBC API doesn't even support MySQL.

http://phplens.com/phpeverywhere/node/view/9

Well, the PHP manual says this:

"The following databases are supported by the Unified ODBC functions: » Adabas D, » IBM DB2, » iODBC, » Solid, and » Sybase SQL Anywhere. "

http://www.php.net/manual/en/ref.uodbc.php


Even for a professional programming project, I might see little problems
with using a vendor specific C API for some cases. Any non-trivial
application, will anyway be written with an abstraction DB layer, hiding
the actual DB interface, whatever it might be... ODBC, C API or embedded
SQL. Writing a new DB layer, to support another DB brack-end, is no
rocket science and will not affect the business logic anyway.

If you use standards based APIs then the database becomes practically
irrelevant. (There is often some porting effort, but it is trivial
compared to changing from one proprietary API to another). If you use
a proprietary API, then the database is cast in stone. Migration
becomes a complete rewrite.

*IF* a new DB backend is needed, this can be done in a well-designed program, I wouldn't consider swapping from e.g. MySQL API to an ODBC back-end such a big deal.

Some 10 years ago, I wrote an ODBC back-end towards a SQL DB located on a mainframe, that was no free lunch, buggy ODBC driver(s) made the debugging a challenge. Back then, even after an ODBC patch was installed on the mainframe, it didn't work as expected. Connections where dropped, blocking network calls elsewhere, made my code freeze... different behavoir on test and prod systems.

My code was part of a CA system, and was managing certificate requests/resposes, certificate status and one-time passwords etc. In a desperate attempt to reach the delivery date, we put the prod system in debug, to find a work-around for the crappy ODBC stuff... late Friday, in a small CA room, behind multiple locks, two people got trapped, when an alarm went off and the doors refused to open. Perfect! There was phone installed, but neither of us knew the number to the guard. LOL

In retrospect, I should have written a mainframe server myself, and used TCP/IP to communicate with it. For sure, no blocking network calls would have been made then, and any errors could have been fixed in time. OTOH, ODBC must be perfect for Java and C++ programmers. *ironic*


--
Tor <torust [at] online [dot] no>
.

Relevant Pages

  • Re: SQL using C
    ... I am almost a new C programmer and now I need to use SQL within my C ... The people who are telling you to use a C API are out of their mind. ... MySQL + PHP), then the MySQL C API is a rather good option to get ... Because ODBC is extremely well documented. ...
    (comp.lang.c)
  • Re: SQL using C
    ... I am almost a new C programmer and now I need to use SQL within my C ... What part of "new C programmer" and "not any experience using SQL" didn't you understand? ... MySQL + PHP), then the MySQL C API is a rather good option to get started with minimum trouble, note that the C and PHP API's are very similar. ... Pulling in extra dependencies via e.g. ODBC, is a *really* bad advice for beginners IMO. ...
    (comp.lang.c)
  • Re: SQL using C
    ... Does anybody have any idea about good examples on SQL using C? ... This C API: ... Dependencies needed for ODBC: ... Dependencies needed for Proprietary API: ...
    (comp.lang.c)
  • Re: TDBC documentation, examples, syntax?
    ... current SQL standards. ... for variable binding at the Tcl level. ... API, I'd probably use Oracle's bound session variables and pass ... As a convenience for driver writers, ...
    (comp.lang.tcl)
  • Re: Sybase Source. What "data flow source" to use?
    ... "Allan Mitchell" wrote: ... when I right-click over a SQL 2005 database and select Import ... datasources defined in ODBC Datasources on my computer, ...
    (microsoft.public.sqlserver.dts)