Bug 30694 - System.Data.Odbc column names contain extra characters
Summary: System.Data.Odbc column names contain extra characters
Status: CONFIRMED
Alias: None
Product: Class Libraries
Classification: Mono
Component: System.Data (show other bugs)
Version: 4.0.0
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-06-02 18:01 UTC by Ryan
Modified: 2015-09-28 09:24 UTC (History)
2 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Screen shot of the debugger inspecting a column name. (87.23 KB, image/png)
2015-06-02 18:01 UTC, Ryan
Details

Description Ryan 2015-06-02 18:01:50 UTC
Created attachment 11443 [details]
Screen shot of the debugger inspecting a column name.

Whenever I query against an ODBC data source using the System.Data.Odbc library (which is a hassle due to the other major issues making System.Data.Odbc barely usable), the column names returned contain a string of extra null characters ending in something that is "almost" the exact opposite of null (char with value FDFF).  This means that my output string is 54 characters long and contains a bunch of garbage after the actual column name.  I am unable to rename the columns directly because then the column name HASH references will then fail since the hash table is apparently not updated when a column is renamed.  Aside from that, the actual values mean that the strings I am passing around in my code, and ultimately printing to the screen aren't correct.  Any successive queries I generated based off of those returned column names fail since the strings don't match any valid column names stored in the database.
Comment 1 Ryan 2015-06-02 18:02:25 UTC
Also, this is happening in version 4.0.1
Comment 2 Marek Safar 2015-06-17 11:24:11 UTC
Please provide steps to reproduce the issue locally.
Comment 3 Ryan 2015-06-17 12:54:18 UTC
Here is a simple program that demonstrates this issue... The use of the factory instance is to replicate the environment in our larger application that uses factories to generalize some of the code base.  This problem only occurs with Odbc data sources, and was not present in mono 3.12.


 using System;
 using System.Data;
 using System.Data.Odbc;
 using System.Data.Common;

 public class Test
 {
    public static void Main(string[] args)
    {
        string connectionString = "DRIVER={MySQL};SERVER=192.168.168.150;PORT=3306;DATABASE=Northwind_Training;UID=root;PASSWORD=dba;OPTION=3";
        DbConnection dbcon;
        dbcon = new OdbcConnection(connectionString);
        dbcon.Open();

        string sqlStmt = "select * from employees where 0=1";
        DbCommand cmnd = System.Data.Odbc.OdbcFactory.Instance.CreateCommand();
        cmnd.Connection = dbcon;
        cmnd.CommandText = sqlStmt;
        DbDataAdapter da = System.Data.Odbc.OdbcFactory.Instance.CreateDataAdapter ();
        da.SelectCommand = cmnd;
        DataTable dt = new DataTable ();
        dt.TableName = "employees"; //Not sure why this is needed
        da.Fill (dt);

        foreach (DataColumn dc in dt.Columns) {
          Console.WriteLine(dc.ColumnName + " : " + dc.ColumnName.Length);
        }

       dbcon.Close();
       dbcon = null;
    }
 }



Compile: mcs odbc_bad_names.cs -r:System.Data
Execute: mono odbc_bad_names.exe

Output:
EmployeeID� : 128
LastName� : 128
FirstName� : 128
Title� : 128
TitleOfCourtesy� : 128
BirthDate� : 128
HireDate� : 128
Address� : 128
City� : 128
Region� : 128
PostalCode� : 128
Country� : 128
HomePhone� : 128
Extension� : 128
Photo� : 128
Notes� : 128
ReportsTo� : 128
PhotoPath� : 128
Comment 4 Ryan 2015-07-08 17:17:39 UTC
Not sure if I needed to update the status after my last post, but I am setting it back to New.  Not sure what other status I should in this case.
Comment 5 Ryan 2015-09-24 14:46:14 UTC
As of the latest version of mono 4.0.4.1, this problem appears to have gotten worse.  This same code now gives me a seg fault while attempting to fill the DbDataAdapter.


Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) System.Data.Odbc.libodbc.SQLExecDirect (intptr,string,int) <0xffffffff>
  at System.Data.Odbc.OdbcCommand.ExecSQL (System.Data.CommandBehavior,bool,string) <0x0005f>
  at System.Data.Odbc.OdbcCommand.ExecuteNonQuery (string,System.Data.CommandBehavior,bool) <0x0009b>
  at System.Data.Odbc.OdbcCommand.ExecuteReader (string,System.Data.CommandBehavior) <0x00023>
  at System.Data.Odbc.OdbcCommand.ExecuteReader (System.Data.CommandBehavior) <0x00023>
  at System.Data.Odbc.OdbcCommand.ExecuteDbDataReader (System.Data.CommandBehavior) <0x00013>
  at System.Data.Common.DbCommand.ExecuteReader (System.Data.CommandBehavior) <0x00018>
  at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader (System.Data.CommandBehavior) <0x00013>
  at System.Data.Common.DbDataAdapter.Fill (System.Data.DataTable,System.Data.IDbCommand,System.Data.CommandBehavior) <0x00079>
  at System.Data.Common.DbDataAdapter.Fill (System.Data.DataTable) <0x00040>
  at (wrapper remoting-invoke-with-check) System.Data.Common.DbDataAdapter.Fill (System.Data.DataTable) <0xffffffff>
  at Test.Main (string[]) <0x00117>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

	mono() [0x4b23dc]
	mono() [0x508a0e]
	mono() [0x428fad]
	/lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10) [0x7f097a5d5d10]
	/usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so(my_SQLPrepare+0x6b) [0x7f09766980cb]
	/usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so(SQLPrepareWImpl+0x6c) [0x7f097669c1bc]
	/usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so(SQLExecDirectW+0x9) [0x7f097669c1d9]
	/usr/lib/libodbc.so(SQLExecDirectW+0xe2) [0x7f0976cfa412]
	[0x40aea2bd]

Debug info from gdb:

Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No threads.

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Aborted (core dumped)
Comment 6 Ryan 2015-09-28 09:21:12 UTC
Turns out that last bug was actually related to the MySQL ODBC driver available in the Ubuntu repositories.  That driver appears to be broken.  The PostgreSQL driver on the other hand is working fine, but still gives the same mangled column names.

I also tried avoiding using the DbDataAdapter, with the same results, which makes me suspect that the base reader for the ODBC library is the source of the problem.  Here is my alternate source, and the output I am getting in that case:


using System;
using System.Data.Odbc;
using System.Data.SqlClient;
using System.Data;

namespace odbc_test
{
    class MainClass
    {
        public static void Main(string[] args)
        {
            string connectionString = "DRIVER={PostgreSQL_ANSI};SERVERNAME=192.168.168.152;DATABASE=University;Username=root;Password=dba";
            string sqlStmt = "select * from class where 0=1";
            DataTable dt = new DataTable();

            using (OdbcConnection oConnection = new OdbcConnection(connectionString))
            {
                // Open a connection
                oConnection.Open();

                using (OdbcCommand cmd = new OdbcCommand(sqlStmt, oConnection))
                {
                    OdbcDataReader dr = cmd.ExecuteReader();
                    dt.Load(dr);
                }
            }

            foreach (DataColumn dc in dt.Columns) {
                Console.WriteLine(dc.ColumnName + " : " + dc.ColumnName.Length);
            }
            System.Console.WriteLine("Press <ENTER> to exit");
            System.Console.ReadLine();
        }
    }
}



OUTPUT:

Id? : 128
Title? : 128
Department? : 128
Professor? : 128
Credits? : 128
Blank? : 128
Comment 7 Ryan 2015-09-28 09:24:54 UTC
From dpkg -l, here is the version of System.Data I currently have installed:

libmono-system-data4.0-cil  4.0.4.1-0xamarin1  Mono System.Data library (for CLI 4.0)

Note You need to log in before you can comment on or make changes to this bug.