System.Data.SQLite

This issue can be reproduced by the following code in WM6.5


            string _connectionString = @"Data Source=db1.db";
            string _sql;

            SQLiteConnection conn = new SQLiteConnection();
            SQLiteCommand cmd;
            conn.ConnectionString = _connectionString;
            conn.Open();


           
         //   _sql = "drop table tb";
         //   cmd = new SQLiteCommand(_sql, conn);
         //   cmd.ExecuteNonQuery();
         //   cmd.Dispose(); 

            _sql = "create table tb( ID integer, content  blob null, content2 blob null)";
            cmd = new SQLiteCommand(_sql, conn);
            cmd.ExecuteNonQuery();

            cmd.Dispose();

            _sql = "insert into tb( ID) values( 10)";
            cmd = new SQLiteCommand(_sql, conn);
            cmd.ExecuteNonQuery();
            cmd.Dispose();
            

            _sql = "update tb set content = zeroblob(10*1024*1024) where rowid = 1";
            cmd = new SQLiteCommand(_sql, conn);
            cmd.ExecuteNonQuery();
            cmd.Dispose();

            _sql = "update tb set content2 = zeroblob(10) where rowid = 1";
            cmd = new SQLiteCommand(_sql, conn);
            cmd.ExecuteNonQuery();  //throw outofmemory exception
            cmd.Dispose();

<hr /><i>mistachkin added on 2011-11-22 22:57:44 UTC:</i><br />
Are you really using version 1.0.65?  Is it possible to reproduce this issue with the latest released version (1.0.76)?

<hr /><i>mistachkin added on 2011-11-27 12:12:39 UTC:</i><br />
I have not been able to reproduce this issue using the latest code on trunk.

<hr /><i>mistachkin added on 2011-11-28 04:08:10 UTC:</i><br />
Reading the code reveals a potential workaround if you are experiencing out-of-memory issues due to a limited amount of total RAM.

After using a command, it should be explicitly disposed (i.e. not simply left to be collected by the GC).  Simply letting it be collected by the GC will not release the memory it references in a timely fashion.  Also, repeating creating and using commands without explicitly disposing them could cause an out-of-memory condition to occur.


<hr /><i>mistachkin added on 2011-12-16 05:05:24 UTC:</i><br />
This may be fixed by check-in [419bfbd2ee].  Could you please try to reproduce the problem with the latest code on trunk?