[Rlib-devel] RLIB-1.3.2 questions, problems and an ODBC fix

[Zoltan B. <zb...@du...>]

Hi,

I am experimenting with this report maker software to finally
deploy it in a multiplatform environment. I make my (GPLed) program
under Fedora Core 3/x86-64 and will compile it for Windows with MingW.

My software is special purpose software for business planning and
invoicing for a subsidiary of the Hungarian national oil company.

I use GTK2 and ODBC as both work under both Linux and Windows.

I have first compiled rlib-1.3.2 with the --enable-utf8 option
because under Fedora Core everything is UTF-8 encoded and GTK2
also has a strong dependence on UTF-8 even on Windows.
The report XML file is UTF-8 encoded, as I typed in some literals
into it with Hungarian accented characters. My PostgreSQL database
is created with UTF-8 encoding.

But UTF-8 in RLIB causes problems. All the literals and the strings
that come from the data source are displayed incorrectly. And on the
terminal, I got "Encoder was NULL" messages.

Here's my code that tries to report something:

-------------------------------------------
char *query =3D "some sqlquery...";

    r =3D rlib_init();
    rlib_add_datasource_odbc(r, "mainsource", "ODBCDSN", "uid", "pwd");
    rlib_add_query_as(r, "mainsource", query, "mainquery");
    rlib_add_report(r, "rlibtest.xml");
    rlib_set_output_format(r, RLIB_FORMAT_PDF);
    rlib_execute(r);
    output_type =3D rlib_get_content_type_as_text(r);
    outbuf =3D rlib_get_output(r);
    output_len =3D rlib_get_output_length(r);

    fn =3D open("out.pdf", O_RDWR|O_CREAT|O_TRUNC);
    if (fn) {
      write(fn, outbuf, output_len);
      close(fn);
    } else
      printf("open() error: %s\n", strerror(errno));

    rlib_free(r);
-------------------------------------------

After I recompiled rlib without UTF-8 support and set
the connection string in the ODBC DSN to
"set client_encoding=3D'ISO-8859-2'" all the string are displayed
correctly. I wasn't surprised by the strings it fetched from the
query, but the literals in the XML file are still UTF-8. (?)
The XML encoding is explicitely UTF-8, as the first line is:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>

OK then, I will have to set up two ODBC DSNs, one for the GTK2
application, one for the report purposes. Not a big problem,
but I would like to use only one. When will the UTF-8 usage
be fixed in RLIB? Nudge, nudge. :-)

The other, more serious problem is that if I use the ODBC
input method in RLIB, the last record is repeated 4 times,
somehow overwriting the first 3 records. And if the query
gave less than 3 records (i.e. 0, 1 or 2) then RLIB crashes.

I.e. my query gave 54 records and for easy comparison,
I put an ORDER BY clause into it. Running the query from psql
shows that the first three records are missing and the
last record is repeated four times in the PDF report produced
by RLIB.  The same happened with the report in text format.

It did not happen when I tried using the native PostgreSQL
call in RLIB, so I took a look into the ODBC input method
and I found a strange next/previous state and row copying
logic. I modified the inputs/odbc/odbc.c and it now uses
SQLFetchScroll(hStmt, SQL_FETCH_{FIRST|NEXT|PRIOR|LAST}, 0)
instead of just SQLFetch(hStmt). It fixed the problem for me.
My ODBC 3.5 Developers Guide says that SQLFetchScroll() is
defined in X/OPEN 95 CLI or under ODBC 3.0+. But it's
CORE Conformance functionality, so it's kind of expected to work
anywhere. Well, except ODBC 2.0 and lower, a.k.a in very old
Win16 drivers. Hm, I just checked the www.unixodbc.org site and
the MySQL and PostgreSQL drivers' ODBC versions are 2.5 and
SQLFetchScroll() definitely works in the unixODBC PostgreSQL
driver. I expect the same from the MySQL ODBC driver.

When the Windows port of RLIB is ready, ODBC will be the first
input method that will work and it must work properly.

So please, consider adding my patch to RLIB-1.3.3 or whatever the
next version is.

I read the policy about patches at http://rlib.sicompos.com
I will print, sign and send the copyright assignment but please
allow me some days to actually do it. I don't have a printer
at present and I am off-work to finish the above mentioned
software, for my second work.

I will definitely send more patches towards you, to fix issues
and warnings that pop up. I already found a solution for the
"langinfo.h is missing under MingW", so one compilation error
is fixed under Windows. The attached ODBC fix at least allows
me to create my reports and test it under Linux.

And I have some warning fixes that follows the GTK2 development
guideline, e.g. replacing (gpointer *)x with GINT_TO_POINTER(x).
The macro works correctly under x86-64, where the explicit
pointer conversion prints warnings.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi