Bug 58578 - EDITING - Actual Technology ODBC opensource DB driver displays spurious padding characters in table on OSX 10.8.2
Summary: EDITING - Actual Technology ODBC opensource DB driver displays spurious paddi...
Status: CLOSED DUPLICATE of bug 58693
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.1.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) macOS (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-12-20 15:55 UTC by Alex Thurgood
Modified: 2013-01-11 20:54 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
comparative screenshot between isql and ActualTech ODBC driver (106.54 KB, image/png)
2012-12-20 15:55 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2012-12-20 15:55:26 UTC
Created attachment 71864 [details]
comparative screenshot between isql and ActualTech ODBC driver

On Mac OSX, it is possible to access mysql and postgresql data sources via the Actual Technologies ODBC driver. This is paying software, but a free trial is available for testing that returns the first three rows of the result set.


On the daily master build :

Version 4.1.0.0.alpha0+ (Build ID: 1e65f0176a9243274971321ffa5b6462130904e)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-20_00:42:24


the display of the table is corrupted by spurious padding characters added after the actual data.

A screenshot comparison showing the data displayed using the ActualTechnologies driver and isql clearly shows this difference.


Alex
Comment 1 Alex Thurgood 2012-12-20 15:56:41 UTC
adding Lionel, Thorsten, Norbert to CC
Comment 2 Alex Thurgood 2012-12-20 15:57:07 UTC
I have contacted Actual Technologies about this with the same information.
Comment 3 Alex Thurgood 2012-12-20 16:08:50 UTC
Tested also with :

LO 334 : even worse display results, virtually all of the varchar/char fields are truncated to the first character of the data string

LO 357 : no problem, displays correctly.

LO 364 : no problem, displays correctly.

So this is definitely a regression introduced somewhere during 3.7/4.0 development.

Marking as such.


Alex
Comment 4 Lionel Elie Mamane 2012-12-20 16:35:13 UTC
Are the affected fields only VARCHAR, or also CHAR?
Comment 5 Alex Thurgood 2012-12-22 10:28:48 UTC
Hi Lionel,


The client field is VARCHAR, the country field is CHAR, so the answer is both. This sounds similar to the bug that we saw in the bibliography db, but I thought that had been fixed ?

Alex
Comment 6 Alex Thurgood 2012-12-22 10:31:29 UTC
(In reply to comment #5)
> Hi Lionel,
> 
> 
> The client field is VARCHAR, the country field is CHAR, so the answer is
> both. This sounds similar to the bug that we saw in the bibliography db, but
> I thought that had been fixed ?
> 
> Alex

The country field is a CHAR(2) field type.

Alex
Comment 7 Lionel Elie Mamane 2012-12-25 12:10:06 UTC

*** This bug has been marked as a duplicate of bug 58693 ***