Quantcast
Channel: ESENT Managed Interface
Viewing all 496 articles
Browse latest View live

Commented Unassigned: Indeces cannot be traversed using Microsoft.Database.Isam [13515]

$
0
0
Traversing indices using FindRecords and FindRecordsBetween does not work because of a bug in the Microsoft.Database.Isam.Cursor::Move method.

I have created my own fork of the repository and changing the following code

```
// setup our index range
if (rows < 0)
{
this.SetUpperLimit();
}
if (rows > 0)
{
this.SetLowerLimit();
}
```

to

```
// setup our index range
if (rows < 0)
{
this.SetLowerLimit();
}
if (rows > 0)
{
this.SetUpperLimit();
}
```

has worked for me. Other users have also reported that this change solves the problem, as it has been discussed in the [Test driving Microsoft.Database.Isam](https://managedesent.codeplex.com/discussions/568888) thread.

I wonder if you could fix this issue as it really is a showstopper. Thx.
Comments: ** Comment from web user: martinc **

Should actually be fixed in 1.9.3.2!

-martin


Closed Unassigned: Indeces cannot be traversed using Microsoft.Database.Isam [13515]

$
0
0
Traversing indices using FindRecords and FindRecordsBetween does not work because of a bug in the Microsoft.Database.Isam.Cursor::Move method.

I have created my own fork of the repository and changing the following code

```
// setup our index range
if (rows < 0)
{
this.SetUpperLimit();
}
if (rows > 0)
{
this.SetLowerLimit();
}
```

to

```
// setup our index range
if (rows < 0)
{
this.SetLowerLimit();
}
if (rows > 0)
{
this.SetUpperLimit();
}
```

has worked for me. Other users have also reported that this change solves the problem, as it has been discussed in the [Test driving Microsoft.Database.Isam](https://managedesent.codeplex.com/discussions/568888) thread.

I wonder if you could fix this issue as it really is a showstopper. Thx.
Comments: Fixed in 1.9.3.2

Closed Unassigned: JetGetColumnInfo does not work on Windows Server 2008 R2 [13696]

$
0
0
The function
```
public int JetGetColumnInfo(
JET_SESID sesid,
JET_DBID dbid,
string tablename,
JET_COLUMNID columnid,
out JET_COLUMNBASE columnbase)
```
does not work correctly under Windows Server 2008 R2 and Windows 7, even in the latest (1.9.3.0) release.

The "Test driving Microsoft.Database.Isam" discussion contains this patch:
```
// Technically, this should have worked in Vista. But there was a bug, and
// it was fixed after Windows 7.
if (this.Capabilities.SupportsWindows8Features)
```
instead of
```
if (this.Capabilities.SupportsVistaFeatures)
```
I confirm that this patch works. Could you please include it in the next release? Thx.
Comments: Fixed in 1.9.3.2

Commented Unassigned: JetGetColumnInfo does not work on Windows Server 2008 R2 [13696]

$
0
0
The function
```
public int JetGetColumnInfo(
JET_SESID sesid,
JET_DBID dbid,
string tablename,
JET_COLUMNID columnid,
out JET_COLUMNBASE columnbase)
```
does not work correctly under Windows Server 2008 R2 and Windows 7, even in the latest (1.9.3.0) release.

The "Test driving Microsoft.Database.Isam" discussion contains this patch:
```
// Technically, this should have worked in Vista. But there was a bug, and
// it was fixed after Windows 7.
if (this.Capabilities.SupportsWindows8Features)
```
instead of
```
if (this.Capabilities.SupportsVistaFeatures)
```
I confirm that this patch works. Could you please include it in the next release? Thx.
Comments: ** Comment from web user: grafnetter **

Great! Thanks, Martin!

Created Unassigned: GetTableColumns broken [13707]

$
0
0
1.9.3.2 - 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

Commented Unassigned: GetTableColumns broken [13707]

$
0
0
1.9.3.2 - 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
Comments: ** Comment from web user: martinc **

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.

-martin

New Post: Backing up or copying a persistentdictionary

$
0
0
Can someone tell me how I can copy or backup a persistentdictionary. I can't seem to find a way of doing this. Thanks.

Commented Unassigned: GetTableColumns broken [13707]

$
0
0
1.9.3.2 - 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
Comments: ** Comment from web user: grafnetter **

The bug is still present in realease 1.9.3.2 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()


Commented Unassigned: GetTableColumns broken [13707]

$
0
0
1.9.3.2 - 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
Comments: ** Comment from web user: martinc **

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?

-martin

Commented Unassigned: GetTableColumns broken [13707]

$
0
0
1.9.3.2 - 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
Comments: ** Comment from web user: grafnetter **

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.

Commented Unassigned: GetTableColumns broken [13707]

$
0
0
1.9.3.2 - 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
Comments: ** Comment from web user: martinc **

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.

-martin

New Post: Possible to store objects that are not strings, url's, etc

$
0
0
How come it won't be updated? That means that every time I alter value I have to remove it and re-insert it?
The data that is stored is a serialized copy. ie it's actually written to the disk. By modifying an object in memory, you are modifying references, you are not modifying the disk. Updating the dictionary would overwrite the serialized form with the current data.

New Post: Backing up or copying a persistentdictionary

$
0
0
If you do a clean shutdown, you can copy the edb file by itself. Be aware that you can't easily go to an older OS, because it isn't written in a format that can be read by older versions of esent.dll

-martin

Closed Unassigned: Persistent Dictionary Concurrency Problem [12714]

$
0
0
I get "Cannot access file, the file is locked or in use" with PersistentDictionary when adding new keys to a single dictionary by multiple processes (programs) simultaneously.

Below is the detailed stack trace -

Cannot access file, the file is locked or in use "at Microsoft.Isam.Esent.Interop.Api.Check(Int32 err)\r\n at Microsoft.Isam.Esent.Interop.Api.JetInit2(JET_INSTANCE& instance, InitGrbit grbit)\r\n at Microsoft.Isam.Esent.Interop.Instance.Init(InitGrbit grbit)\r\n at Microsoft.Isam.Esent.Collections.Generic.PersistentDictionary`2..ctor(String directory)".

Any suggestions?
Comments: The PersistentDictionary object can only be created once per file.

Created Unassigned: Floating-point invalid operation [13847]

$
0
0
Folks, this is just a warning about something scary that happened today. I just migrated my whole development environment from Win7 to Win10 on a brand new PC. I have a REST style web service that uses ManagedEsent as backing storage for persisting settings and session state. I received the following crash in native code during Web App_Startup where it called Instance Init:

```
Unhandled exception at 0x00007FF96762D349 (esent.dll) in w3wp.exe: 0xC0000090:
Floating-point invalid operation (parameters: 0x0000000000000000, 0x0000000000001921).
```

For hours I tried all sorts of tricks to diagnose this problem without success. Eventually, almost on an instinctive whim, I lazily initialized the property over the database so that the first request caused it to initialize. This fixed the problem. I have no idea what was wrong or why it was fixed, but I presume the newer IIS version has subtly different behavior and perhaps the IIS worker process environment is not the same during startup as the old one. In any case, a floating point crash in esent.dll is quite startling.

_Greg_

Released: ManagedEsent 1.9.3.3 (Mar 09, 2016)

$
0
0
1.9.3.3. Some more bug and performance fixes. Subversion was pretty flaky, so we've migrated to git. This binary has some source changes that weren't checked in to Subversion, and will later be checked in to git.

Created Release: ManagedEsent 1.9.3.3 (Mar 09, 2016)

$
0
0
1.9.3.3. Some more bug and performance fixes. Subversion was pretty flaky, so we've migrated to git. This binary has some source changes that weren't checked in to Subversion, and will later be checked in to git.

Source code checked in, #88b673c69aea161ff140b89f0bca993f94f8c269

$
0
0
ManagedEsent 1.9.3.3. Some bug/perf fixes; started adding Isam unit tests.

Created Unassigned: Invalid API Parameter on Windows Server 2008R2 [13848]

$
0
0
I developed a web app on windows 7 in C# visual studio 2015 and using iisexpress. When launching esent will initialize correctly with a supplied directory and i can create a persistent dictionary and read/write keys. Once I move my app to a windows server 2008r2 box, I get an error during initialization: Microsoft.Isam.Esent.Interop.EsentInvalidParameterException: Invalid API parameter.

Any idea on why I'm getting this error? I've tried a few things like checking to make sure my service account has permissions, modifying the app pool to allow 32bit or not, and a various other changes to no effect.

Commented Unassigned: Invalid API Parameter on Windows Server 2008R2 [13848]

$
0
0
I developed a web app on windows 7 in C# visual studio 2015 and using iisexpress. When launching esent will initialize correctly with a supplied directory and i can create a persistent dictionary and read/write keys. Once I move my app to a windows server 2008r2 box, I get an error during initialization: Microsoft.Isam.Esent.Interop.EsentInvalidParameterException: Invalid API parameter.

Any idea on why I'm getting this error? I've tried a few things like checking to make sure my service account has permissions, modifying the app pool to allow 32bit or not, and a various other changes to no effect.
Comments: Ah, I just realized it's a 2008 server not R2. I wonder if I need to initiate the persistent dictionary differently. Currently it's like this: instance.db = new PersistentDictionary<string, string>(Current.Settings.Site.EsentPath);
Viewing all 496 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>