This project has moved and is read-only. For the latest updates, please go here.

GetTableColumns broken

description - The overloaded method with signature GetTableColumns(JET_SESSID, JET_DBID, string) returns garbage column names. The other overload produces correct names.

The attached image shows a pause in the debugger and tooltip with the offending column names.

Greg K

file attachments


martinc wrote Sep 14, 2015 at 11:49 PM

Thanks Greg.

There is a test for that (HelpersTests.cs: GetTableColumnsByTableNamesTest() ), so it isn't completely broken! But it might be broken on your OS.If you are running Windows Vista or 7, then this bug should be fixed in the newest release of ManagedEsent. JetApi.JetGetColumnInfo() didn't work for Unicode on Vista or Win7.


grafnetter wrote Oct 28, 2015 at 11:05 AM

The bug is still present in realease running on Windows 7 and Windows Server 2008 R2.I always get ArgumentException with message "Cannot marshal: Encountered unmappable character.".

Stack trace:

at System.String.ConvertToAnsi(Byte* pbNativeBuffer, Int32 cbNativeBuffer, Boolean fBestFit, Boolean fThrowOnUnmappableChar) at System.StubHelpers.CSTRMarshaler.ConvertToNative(Int32 flags, String strManaged, IntPtr pNativeBuffer) at Microsoft.Isam.Esent.Interop.Implementation.NativeMethods.JetGetColumnInfo(IntPtr sesid, UInt32 dbid, String szTableName, String szColumnName, NATIVE_COLUMNBASE& columnbase, UInt32 cbMax, UInt32 InfoLevel) at Microsoft.Isam.Esent.Interop.Implementation.JetApi.JetGetColumnInfo(JET_SESID sesid, JET_DBID dbid, String tablename, String columnName, JET_COLUMNBASE& columnbase) at Microsoft.Isam.Esent.Interop.Api.JetGetColumnInfo(JET_SESID sesid, JET_DBID dbid, String tablename, String columnName, JET_COLUMNBASE& columnbase) at Microsoft.Database.Isam.ColumnDefinition.Load(IsamDatabase database, String tableName, JET_COLUMNLIST columnList) at Microsoft.Database.Isam.ColumnEnumerator.get_Current()

martinc wrote Oct 29, 2015 at 3:43 PM

Hello Grafnetter,

I tried the 'ColumnInfoTests' on Win7, and they run just fine for me.

Are you able to run those tests? Do they fail for you?Does this happen with every database?Are there Unicode names in any of the columns? Indices?Does it work if you use the ManagedEsent layer directly? Or only with the Microsoft.Database.Isam DLL?


grafnetter wrote Nov 2, 2015 at 10:45 PM

Hi Martin,

this ISAM code fails for me on W7:

TableDefinition table = database.Tables["Data"];foreach(var column in in table.Columns) { }

No, the column name does not contain any non-ascii characters. Loading its name this way works:

string columnName = Api.RetrieveColumnAsString( database.IsamSession.Sesid, columnList.tableid, columnList.columnidcolumnname, Encoding.ASCII);

But if Encoding.Unicode is used instead, total gibberish is loaded into columnName. It looks like Chinese characters. My understanding of it is that 2 subsequent ASCII characters are being interpreted as 1 UTF-16 character. When this happens, the next call throws the exception I have described in my previous comment:

Api.JetGetColumnInfo(database.IsamSession.Sesid, database.Dbid, tableName, columnName, out columnbase);

The problem might have something to do with this code:

// If we use the wide API (Vista+), then the temp table will be in UTF-16. Encoding encodingOfTextColumns = EsentVersion.SupportsVistaFeatures ? Encoding.Unicode : Encoding.ASCII;

And it of course evaluates to Encoding.Unicode on Windows 7.

The GetTableColumnsByTableNamesTest FAILS with KeyNotFoundException on my "Windows 7 Professional SP1 64-bit" with the most current updates.

Again, everything runs normally on Win8.

martinc wrote Nov 20, 2015 at 12:31 AM

Sorry for the delay -- I was on vacation last week.

Thanks, that function is indeed the likely culprit. Thanks a lot for tracking it down!I really need to add those unit tests for Isam, to find issues like this proactively.


grafnetter wrote Apr 3, 2016 at 9:14 AM

It seems that this bug has been fixed in release Thx.

nblumhardt wrote Apr 7 at 12:51 AM

Would this also possibly apply to I've just opened a discussion about another issue with the same API:

Thanks in advance! :-)

grafnetter wrote Apr 9 at 9:13 AM

@nblumhardt Yes. You should definitely upgrade to the latest version.

nblumhardt wrote Apr 13 at 2:42 AM

@grafnetter thanks, I'll do that.