Overflow exception from SQL in only 64 bit applications

Question

I have an ODBC database running on an AS400. I have created a connection string to connect to the database and run queries. All of my queries run just fine when I compile the program to 32 bit but when I compile them to 64 bit I get an Overflow exception. Unfortunately I have to compile my program to 64 bit.

What could be causing this issue and how might I fix it?

More info:
The driver I'm using is iSeries Access ODBC Driver
All of my database columns are either strings or decimals
I am using a connection string not a DNS
The connection string I'm using is
"Driver={iSeries Access ODBC Driver};uid=XXX;data provider=ODBC;system=XXX;dbq=XXX;pwd = XXX"

I appreciate any help.

The code looks like this:

MPDCHFTableAdapter configs = new MPDCHFTableAdapter();
variants = configs.GetDataByProduct("98.M1BODY");  

The stack trace is:

System.OverflowException was unhandled
  HResult=-2146233066
  Message=Arithmetic operation resulted in an overflow.
  Source=System.Data
  StackTrace:
       at System.Data.Odbc.OdbcDataReader.GetSqlType(Int32 i)
       at System.Data.Odbc.OdbcDataReader.GetFieldType(Int32 i)
       at System.Data.ProviderBase.SchemaMapping.SetupSchemaWithoutKeyInfo(MissingMappingAction mappingAction, MissingSchemaAction schemaAction, Boolean gettingData, DataColumn parentChapterColumn, Object chapterValue)
       at System.Data.ProviderBase.SchemaMapping..ctor(DataAdapter adapter, DataSet dataset, DataTable datatable, DataReaderContainer dataReader, Boolean keyInfo, SchemaType schemaType, String sourceTableName, Boolean gettingData, DataColumn parentChapterColumn, Object parentChapterValue)
       at System.Data.Common.DataAdapter.FillMappingInternal(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 schemaCount, DataColumn parentChapterColumn, Object parentChapterValue)
       at System.Data.Common.DataAdapter.FillMapping(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 schemaCount, DataColumn parentChapterColumn, Object parentChapterValue)
       at System.Data.Common.DataAdapter.FillFromReader(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 startRecord, Int32 maxRecords, DataColumn parentChapterColumn, Object parentChapterValue)
       at System.Data.Common.DataAdapter.Fill(DataTable[] dataTables, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)
       at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
       at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)
       at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)
       at M3DataSorting.M3DataTableAdapters.MPDCHFTableAdapter.GetDataByProduct(String QIPRNO) in u:\Visual Studio 2012\Projects\M3DataSorting\M3DataSorting\M3Data.Designer.cs:line 8280
       at M3DataSorting.Program.update98SLURRY() in u:\Visual Studio 2012\Projects\M3DataSorting\M3DataSorting\Program.cs:line 314
       at M3DataSorting.Program.Main(String[] args) in u:\Visual Studio 2012\Projects\M3DataSorting\M3DataSorting\Program.cs:line 61
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

Answer 1

I'v found that using an OLE driver instead of ODBC prevents this problem from happening. Still not sure what the problem was though.