using spatialite on C# VS2008 SP1, Windows7 64 bit

[Mitch]

I am trying to use Spatialite in a .NET application using the
System.Data.SQLite provider.

I have tried to load 'libspatialite-2.dll' but an error happens when I
call function "ExecuteStatement(@"SELECT
load_extension('libspatialite-2.dll')", connection);"

The specific error is "Attempted to read or write protected memory.
This is often an indication that other memory is corrupt."

I am using VS2008 SP1, .net Framework 3.5 SP1, Windows7 64bit.

Here's my source code :

class Program
{
const string mydb = @"d:\world.sqlite";

static void Main(string[] args)
{
using (SQLiteConnection connection = new
SQLiteConnection(@"Data Source=" + mydb))
{
connection.Open();

ExecuteStatement(@"PRAGMA foreign_keys = ON",
connection);

ExecuteStatement(@"SELECT
load_extension('libspatialite-2.dll')", connection);

}
}
private static void ExecuteStatement(string statement,
SQLiteConnection connection)
{
using (SQLiteCommand command = new
SQLiteCommand(statement, connection))
{
command.ExecuteNonQuery();
}
}
}



< error message > :
System.Data.SQLite.SQLite3.Step(SQLiteStatement stmt)
System.Data.SQLite.SQLiteDataReader.NextResult()
System.Data.SQLite.SQLiteDataReader..ctor(SQLiteCommand cmd,
CommandBehavior behave)
System.Data.SQLite.SQLiteCommand.ExecuteReader(CommandBehavior
behavior)
System.Data.SQLite.SQLiteCommand.ExecuteNonQuery()
ConsoleApplication1.Program.ExecuteStatement(String statement,
SQLiteConnection connection) file C:\Users\Mitch\Desktop\TEST
\ConsoleApplication1\ConsoleApplication1\Program.cs: line 36
ConsoleApplication1.Program.Main(String[] args) file C:\Users\Mitch
\Desktop\TEST\ConsoleApplication1\ConsoleApplication1\Program.cs:line
28
System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state)
System.Threading.ThreadHelper.ThreadStart()</
StackTrace><ExceptionString>System.AccessViolationException: Attempted
to read or write protected memory. This is often an indication that
other memory is corrupt
System.Data.SQLite.UnsafeNativeMethods.sqlite3_step(IntPtr stmt)

[Brad Hards]

On Wednesday 13 June 2012 11:59:02 Mitch wrote:
> I am trying to use Spatialite in a .NET application using the
> System.Data.SQLite provider.
>
> I have tried to load 'libspatialite-2.dll' but an error happens when I
> call function "ExecuteStatement(@"SELECT
> load_extension('libspatialite-2.dll')", connection);"
>
> The specific error is "Attempted to read or write protected memory.
> This is often an indication that other memory is corrupt."

This is an indication you are mixing sqlite versions - the version on your
system is not the same as the version that is compiled into the almagmation
build of spatialite.

Brad

[maniezzo]

Try to force a 32 bit deploy. In my case, working with VS2010 and .net
4.0, connection string "Data Source=prova.sqlite;Version=3;" I had no
problem. On 64 bit it did not work, too.
Just a little caveat I'm going to ask next in a question ...

v.

[Mitch]

I'm using -
SQLite Version : sqlite-netFx35-binary-bundle-x64-2008-1.0.81.0
Spatialite Version : spatialite-3.0.1-DLL-win-amd64

[Brad Hards]

I'm not all that familiar with this, but SpatiaLite 3.0.1 appears to have been
shipped with SQLite 3.7.9. Best guess is that this corresponds to something
like 1.0.77.0 of the sqlite .net binaries.

You may also be able to use 32 bit binaries.

Brad

[Mitch]

Thank you for your help, Brad

I'm gonna try to use 32bit bins...

Have a nice day.

[a.fu...@lqt.it]

Just few sparse general order considerations:
using libspatialite on Java, C# .NET and PHP (and probably
on many other language bindings) isn't always as plain and
easy as you can expect.

The common issue seems to be always the same for all languages:
the connector module links some libsqlite of its own whilst
libspatialite links a different libsqlite copy (possibly of
a completely different version).
On Linux the situation seems to be slightly better: smarter
overall system design, few well known centralized directories
for shared libraries, many users can easily rebuild from scratch
the whole sw stack on their owns.

On Windows platforms chaos reigns supreme: DLL hell, many users
tends to collect prebuilt DLLs here and there from different
suppliers mixing all them quite at random, there is a higher
probability to encounter some severe mutual incompatibility.

This surely is a sad and unconfortable situation for many users,
but there is very little we can do as the spatialite's devel team;
it's mainly determined by system packagers choices (very often
completely unclear and undocumented).

Just a final consideration: I've never used .NET on my life,
and I'm a very sporadic Java / PHP user (more or less I suppose
the same is for Brad). So our first hand experience is very
near to zero, so we can simply support the community on
the basis of "theoretic / inductive" considerations ;-)

I strongly feel that a stricter cooperation between users
interested in the same language bindings could surely help:
i.e. sharing positive and successful experiences, posting
quick recipes and tutorials, and so on.

bye Sandro




--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.