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

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

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

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

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=;PORT=3306;DATABASE=Northwind_Training;UID=root;PASSWORD=dba;OPTION=3";
        DbConnection dbcon;
        dbcon = new OdbcConnection(connectionString);

        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 = null;

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

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, this problem appears to have gotten worse.  This same code now gives me a seg fault while attempting to fill the DbDataAdapter.


  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]

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=;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

                using (OdbcCommand cmd = new OdbcCommand(sqlStmt, oConnection))
                    OdbcDataReader dr = cmd.ExecuteReader();

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


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  Mono System.Data library (for CLI 4.0)
Comment 8 Marek Safar 2018-02-22 22:39:00 UTC
Mono 5.10 has significantly improved System.Data implementation which should resolve this issue. If you can still reproduce it please reopen the issue.