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

[Bob D. <bd...@si...>]

Hello,

On Mon, 2005-04-11 at 13:47 +0200, Zoltan Boszormenyi wrote:
> 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.

Cool!

> 
> 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.

One of the reasons UTF-8 support is half ass in RLIB is because UTF-8
PDF Support is not there at all.

> 
> 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 = "some sqlquery...";
> 
>     r = 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 = rlib_get_content_type_as_text(r);
>     outbuf = rlib_get_output(r);
>     output_len = rlib_get_output_length(r);
> 
>     fn = 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='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:

You should probably make your encoding "ISO-8859-2" in the xml here in
order to make the characters come out correctly.

> 
> <?xml version="1.0" encoding="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. :-)

If you make RLIB compile in windows with MingGW I'll make sure UTF-8
Support works for you :).  Cygwin/mingw and -mno-cygwin have been
driving me nuts trying to make windows DLL's


> 
> 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.

Yes.  I never use the ODBC stuff and I did it a year ago for some dude
as a favor and I never maintained it or really checked that it worked
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.

Cool!  Thanks

> 
> 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.

Great!

> 
> 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.

Thanks!

Patch looks nice.  I'll apply it as soon as you sign the copyright
assignment.

- Bob