python/sqlite: "sqlite3-rtree-geometry-callback" not found in "C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll"

[hellik]

from the GRASS dev-ML:

​http://lists.osgeo.org/pipermail/grass-dev/2012-October/060216.html ​http://lists.osgeo.org/pipermail/grass-dev/2012-October/060217.html ​http://lists.osgeo.org/pipermail/grass-dev/2012-October/060218.html

and also a windows error-message pops up:
"sqlite3-rtree-geometry-callback" not found in the dll "sqlite3.dll"

see in the spatialite-user-group

​spatialite-user-group

sqlite3_rtree_geometry_callback is indeed not part of the sqlite3 extension API. 

PATCH PROPOSAL FOR THE NEXT UPDATE (3.0.2)
==========================================
invert the default behavior for the compile-time flag:
OMIT_GEOMETRY_CALLBACKS=yes
so to automatically disable this extension in any standard build.

[hellik]

Replying to hellik:

and also a windows error-message pops up:
"sqlite3-rtree-geometry-callback" not found in the dll "sqlite3.dll"

the osgeo4w-grass7.0dev is unusable at the moment because of the missing sqlite3-rtree-functionality.

enabling this in sqlite3 by

./configure SQLITE_ENABLE_RTREE=1 --build=mingw32 --target=mingw32

Helmut

[brushtyler]

Replying to hellik:

"sqlite3-rtree-geometry-callback" not found in the dll "sqlite3.dll"

the osgeo4w-grass7.0dev is unusable at the moment because of the missing sqlite3-rtree-functionality.

enabling this in sqlite3 by

./configure SQLITE_ENABLE_RTREE=1 --build=mingw32 --target=mingw32

In OSGeo4W it's spatialite v3.0.1-2, so the PATCH PROPOSAL FOR THE NEXT UPDATE (3.0.2) refers to spatialite (since sqlite3 is v3.7.10-2).

I can update the sqlite3 package, configuring it with SQLITE_ENABLE_RTREE=1 to make grass7 working again.

But what about spatialite? Should I re-build it with OMIT_GEOMETRY_CALLBACKS=yes to avoid further problems?

[hellik]

Replying to brushtyler:

But what about spatialite? Should I re-build it with OMIT_GEOMETRY_CALLBACKS=yes to avoid further problems?

I've just asked in the ​spatialite-user-group

Helmut

[brushtyler]

Replying to hellik:

I've just asked in the ​spatialite-user-group

Here's the correct link ​https://groups.google.com/forum/?fromgroups=#!topic/spatialite-users/6JwpOVu3NUM

[hellik]

Replying to brushtyler:

Replying to hellik:

I've just asked in the ​spatialite-user-group

Here's the correct link ​https://groups.google.com/forum/?fromgroups=#!topic/spatialite-users/6JwpOVu3NUM

here the answer from the spatialite ML

SQLite introduced the sqlite3_rtree_geometry_callback() API about
one or two years ago; so if you are using some very old libsqlite3
this symbol will not be defined.

Please note: SpatiaLite discourages using the Geometry Callback
based interface, and will be disabled by default in any new
version.
so the suggested solution when building splite is to always define:

DISABLE_GEOMETRY_CALLBACKS

bye Sandro 

[hellik]

Replying to brushtyler:

I can update the sqlite3 package, configuring it with SQLITE_ENABLE_RTREE=1 to make grass7 working again.

another entry regarding this issue in in the grass-user-ML (​http://lists.osgeo.org/pipermail/grass-user/2012-October/065948.html).

what to do improve the situation?

all the best Helmut

[neteler]

People start to suggest in the mailing list to replace the broken OSGeo4W DLL with this one:

​http://www.dll-files.com/dllindex/dll-files.shtml?sqlite3

I don't believe that this is good for our reputation...

[brushtyler]

I'm abroad and I've no win here. I'll be back tomorrow. If someone can/want to fix the problem before tomorrow, just take the ownership of the ticket.

Replying to neteler:

... to replace the broken OSGeo4W DLL ...

First, the DLL is not broken as it worked for months. Probably instead there was some changes in grass-dev the last weeks that require the missing (as disabled by default) functionality, otherwise this problem would came out 8 months ago.

I don't believe that this is good for our reputation...

Fell free to update it, I'm unable to do it until tomorrow.

[brushtyler]

I've built the sqlite3.dll using mingw by ./configure SQLITE_ENABLE_RTREE=1 --build=mingw32 --target=mingw32 (though the nmake.opt file I used the last time set SQLITE_ENABLE_RTREE=1 as well),

but running grass7-dev after copying the DLL in OSGeo4W/bin it still raises the error.

In the traceback I see that grass7 uses python ctypes to load the DLL, so I tried to do the same from OSGeo4W shell and using python ctypes I can find the function within the DLL and load it.

So, are you sure the problem is not within the grass7 code?

[brushtyler]

Replying to brushtyler:

So, are you sure the problem is not within the grass7 code?

Is there anyone that made grass7 working again in his system by replacing the sqlite3.dll from OSGeo4W with a different one?

If yes, than probably I've more that one sqlite3.dll in my system and one of them blind the right one (and I've to try again on a clean win installation).

[hellik]

Replying to brushtyler:

I've built the sqlite3.dll using mingw by ./configure SQLITE_ENABLE_RTREE=1 --build=mingw32 --target=mingw32 (though the nmake.opt file I used the last time set SQLITE_ENABLE_RTREE=1 as well),

but running grass7-dev after copying the DLL in OSGeo4W/bin it still raises the error.

In the traceback I see that grass7 uses python ctypes to load the DLL, so I tried to do the same from OSGeo4W shell and using python ctypes I can find the function within the DLL and load it.

So, are you sure the problem is not within the grass7 code?

thanks for your effort!

but shouldn't it be the other way around, suggested by Sandro (see ​https://trac.osgeo.org/osgeo4w/ticket/305#comment:5):

(disable/no SQLITE_ENABLE_RTREE in sqlite) and disable DISABLE_GEOMETRY_CALLBACKS in spatialite?

Helmut

[neteler]

Replying to brushtyler:

Replying to brushtyler:

So, are you sure the problem is not within the grass7 code?

Is there anyone that made grass7 working again in his system by replacing the sqlite3.dll from OSGeo4W with a different one?

If yes, than probably I've more that one sqlite3.dll in my system and one of them blind the right one (and I've to try again on a clean win installation).

A user wrote to me that he replaced the file in c:/OSGeo4W/apps/python27/DLLS with the one downloaded from a separate site (URL mentioned in comment 8).

[hellik]

Replying to neteler:

A user wrote to me that he replaced the file in c:/OSGeo4W/apps/python27/DLLS with the one downloaded from a separate site (URL mentioned in comment 8).

just tried here with a manually replacement by the above mentioned sqlite3.dll, there pops up the same error message.

[hellik]

Replying to hellik:

Replying to neteler:

A user wrote to me that he replaced the file in c:/OSGeo4W/apps/python27/DLLS with the one downloaded from a separate site (URL mentioned in comment 8).

just tried here with a manually replacement by the above mentioned sqlite3.dll, there pops up the same error message.

sorry, to fast

it seems there are two sqlite3.dll shipped by osgeo4w(packages):

C:\OSGeo4W\bin\sqlite3.dll C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll

[hellik]

Replying to hellik:

sorry, to fast

it seems there are two sqlite3.dll shipped by osgeo4w(packages):

C:\OSGeo4W\bin\sqlite3.dll C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll

(1) replacing C:\OSGeo4W\bin\sqlite3.dll, the same error message

(2) replacing C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll, osgeo4w-wingrass7 starts

[brushtyler]

Why that sqlite3.dll is duplicated???

It works just removing the C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll.

[hellik]

Replying to brushtyler:

Why that sqlite3.dll is duplicated???

It works just removing the C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll.

(1) C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll => python (osgeo4w-python is based on ​http://www.python.org/ftp/python/2.7.2/python-2.7.2.msi) ships sqlite as its own database-engine

(2) C:\OSGeo4W\bin\sqlite3.dll is based upon the osgeo4w-sqlite-package

in windows if e.g. python is called, it searches first for dll's in its own (sub)folders, before subsequently in folders belonging to %PATH% ... a little bit of windows-dll-hell...

Helmut

[hellik]

Replying to brushtyler:

Why that sqlite3.dll is duplicated???

It works just removing the C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll.

can you try DISABLE_GEOMETRY_CALLBACKS in spatialite?

Helmut

[brushtyler]

Replying to hellik:

can you try DISABLE_GEOMETRY_CALLBACKS in spatialite?

yes, I can (and I'm doing it), but I guess this won't fix the problem.

BTW, in SpatiaLite 3.0.1 (the version shipped with OSGeo4W) the name of the flag is OMIT_GEOCALLBACKS, probably it was changed to DISABLE_GEOMETRY_CALLBACKS in the last splite version.

[brushtyler]

Replying to hellik:

Replying to brushtyler:

Why that sqlite3.dll is duplicated???

It works just removing the C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll.

(1) C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll => python (osgeo4w-python is based on ​http://www.python.org/ftp/python/2.7.2/python-2.7.2.msi) ships sqlite as its own database-engine

but since we are putting that python within OSGeo4w it's probably better to remove the sqlite3.dll shipped with python2.7 and set the osgeo4w-sqlite3 package required from the osgeo4w-python one.

in windows if e.g. python is called, it searches first for dll's in its own (sub)folders, before subsequently in folders belonging to %PATH% ... a little bit of windows-dll-hell...

We are trying to avoid the windows-dll-hell, so I'm wondering if there is a good reason to keep that sqlite3.dll within the Python27\DLLs folder and not just use the other one.

[hellik]

Replying to brushtyler:

Replying to hellik:

can you try DISABLE_GEOMETRY_CALLBACKS in spatialite?

yes, I can (and I'm doing it), but I guess this won't fix the problem.

BTW, in SpatiaLite 3.0.1 (the version shipped with OSGeo4W) the name of the flag is OMIT_GEOCALLBACKS, probably it was changed to DISABLE_GEOMETRY_CALLBACKS in the last splite version.

I've just done a ./configure --help in the libspatialite-3.0.1-source within the osgeo4w-msys:

`configure' configures libspatialite 3.0.1 to adapt to many kinds of systems.
[...]
  --enable-geocallbacks   enables geometry callbacks [default=yes]

maybe time to ask Sandro as developer of spatialite to avoid confusion (I'm a little bit)?

[hellik]

Replying to brushtyler:

We are trying to avoid the windows-dll-hell, so I'm wondering if there is a good reason to keep that sqlite3.dll within the Python27\DLLs folder and not just use the other one.

it's beyond my knowledge what's the 'right' solution?

C:\OSGeo4W\bin\sqlite3.dll and C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll are maybe different versions compiled with different compiling options?

and it seems all osgeo4w-packages are built against C:\OSGeo4W\bin\sqlite3.dll and therefore the dll-(function)-mismatch; no idea about further consequences of 'deleting' Python27\DLL\sqlite3.dll

[brushtyler]

Replying to hellik:

Replying to brushtyler:

in SpatiaLite 3.0.1 (the version shipped with OSGeo4W) the name of the flag is OMIT_GEOCALLBACKS, probably it was changed to DISABLE_GEOMETRY_CALLBACKS in the last splite version.

  --enable-geocallbacks   enables geometry callbacks [default=yes]

--enable-geocallbacks=no sets the flag OMIT_GEOCALLBACKS that does NOT define the geometry_callback functions (i.e. sqlite3_rtree_geometry_callback) within the spatialite library.

So disabling the geometry callbacks in spatialite lib cannot make grass7-dev working again.

[brushtyler]

Replying to hellik:

C:\OSGeo4W\bin\sqlite3.dll and C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll are maybe different versions compiled with different compiling options?

yes.

no idea about further consequences of 'deleting' Python27\DLL\sqlite3.dll

AFAICS there's no maintainer for the python package (see ​Package versions)

I guess the sqlite3.dll in Python27\DLLs is compiled using the default settings, but I'm not sure.

[hellik]

Replying to brushtyler:

Replying to hellik:

Replying to brushtyler:

in SpatiaLite 3.0.1 (the version shipped with OSGeo4W) the name of the flag is OMIT_GEOCALLBACKS, probably it was changed to DISABLE_GEOMETRY_CALLBACKS in the last splite version.

  --enable-geocallbacks   enables geometry callbacks [default=yes]

--enable-geocallbacks=no sets the flag OMIT_GEOCALLBACKS that does NOT define the geometry_callback functions (i.e. sqlite3_rtree_geometry_callback) within the spatialite library.

So disabling the geometry callbacks in spatialite lib cannot make grass7-dev working again.

forwarded from the spatialite-ML (and to the GRASS-dev-ML):

> in SpatiaLite? 3.0.1 (the version shipped with OSGeo4W) the name
> of the flag is OMIT_GEOCALLBACKS, probably it was changed to
> DISABLE_GEOMETRY_CALLBACKS in the last splite version.
>

there is absolutely no contradiction (no change) in this.
reality is much more simple: OSGeo4W doesn't uses the canonical build
scripts; it's based instead on the proprietary MSVC compiler.
and in this environment canonical ./configure scripts are nicely
unsupported at all.

./configure --enable-geocallbacks=[yes|no]

this will automatically set as appropriate an internal C flag named
OMIT_GEOCALLBACKS, and will silently set any Makefile as required.
OSGeo4W skips at all the "abstract level" handled by the ./configure
script, directly jumping to the "raw level" of Makefiles and C code;
so the canonical --enable-geocallbacks or --disable-geocallbacks
options are surely invisible from their own perspective, and they
can simply interact with the OMIT_GEOCALLBACKS flag.


>  So disabling the geometry callbacks in spatialite lib cannot make
> grass7-dev working again.
>
> any idea?
>

looks like a grass7-dev specific problem; very probably some of their
modules are still using the deprecated geo-callbacks methods, that
are now disabled by default and that will be definitely removed from
future versions of spatialite.
correcting the C code so to switch from geo-callbacks to the most
recent
VirtualSpatialIndex interface is a very simple operation, just
requiring
to rewrite the SQL queries accessing the Spatial Index.
Not at all a complex patch.

bye Sandro

[jef]

Replying to hellik:

OSGeo4W doesn't uses the canonical build scripts;

It doesn't need to as python is repackaged from the python.org binaries.

[jef]

Replying to jef:

Replying to hellik:

OSGeo4W doesn't uses the canonical build scripts;

It doesn't need to as python is repackaged from the python.org binaries.

ok, scratch that - apparently he's not talking about the python build, but about the spatialite build. Still the python.org binaries are also built with MSVC.

[esseffe]

Sorry, but I'm completely unable to understand why SpatiaLite is supposed to be anyway related to this topic. the reported error message clearly states:

"sqlite3-rtree-geometry-callback" not found in the dll "sqlite3.dll"

and on sqlite3.c (v. 3.7.14.1, current version of SQLite) near line 7633:

SQLITE_API int sqlite3_rtree_geometry_callback(
  sqlite3 *db,
  const char *zGeom,
#ifdef SQLITE_RTREE_INT_ONLY
  int (*xGeom)(sqlite3_rtree_geometry*, int n, sqlite3_int64 *a, int *pRes),
#else
  int (*xGeom)(sqlite3_rtree_geometry*, int n, double *a, int *pRes),
#endif
  void *pContext
);

so if the link symbol "sqlite3-rtree-geometry-callback" isn't properly exported by sqlite3.dll, this is directly related to the build process of libsqlite itself, and for sure has nothing to do with spatialite own configuration options.

bye Sandro

[brushtyler]

Replying to esseffe:

Sorry, but I'm completely unable to understand why SpatiaLite is supposed to be anyway related to this topic.

spatialite is not related at all, as well as the sqlite3 in \bin (the one I built).

I'm still writing that the problem is that grass7-dev uses the wrong sqlite3.dll, the one shipped with python.

We have to choose if replace (or better remove) that DLL, otherwise the grass7-dev code has to be changed to use the sqlite3.dll in \bin (passing the full path to ctypes when loading the sqlite3.dll library).

I would prefer to remove the duplication.

AFAICS in the .vcprops files of the python source package, the Python27\DLLs\sqlite3.dll is compiled using default settings (for that reason it doesn't contain the sqlite3_rtree_geometry_callback function).

[brushtyler]

Any news? Is this issue critical anymore? Could it be fixed on the GRASS side?

BTW the win-dll-hell issue is still there, OSGeo4W ships two different sqlite3.dll. We need a solution for that, but IMHO the priority can be decreased.

[martinl]

Replying to brushtyler:

Any news? Is this issue critical anymore? Could it be fixed on the GRASS side?

yes, it's still critical. It could be fixed on GRASS side. But I think it would be better to fix it on OSGeo4W side, ie. ship only one sqlite3.dll.

BTW the win-dll-hell issue is still there, OSGeo4W ships two different sqlite3.dll. We need a solution for that, but IMHO the priority can be decreased.

Yes, please.

Martin

[jef]

removing the DLL from the python package and introducing a dependency to sqlite3 is easy. Did somebody verify that that doesn't introduce other problems?

[MilenaN]

Hi, I do not use osgeo4w on this computer but maybe it can be a hint:

I couldn't open grass7 installed from ​http://wingrass.fsv.cvut.cz/grass70 I found 3 sqlite3.dll files: C:\Program Files\GRASS GIS 7.0.svn\sqlite\bin\sqlite3.dll

C:\Program Files\GRASS GIS 7.0.svn\extralib\sqlite3.dll

C:\Program Files\GRASS GIS 7.0.svn\Python27\DLLs\sqlite3.dll which is bigger than the other two, so I renamed it. That made grass7 work.

[hellik]

Replying to jef:

Did somebody verify that that doesn't introduce other problems?

I've tested a renamed sqlite3.dll (C:\OSGeo4W\apps\Python27\DLLs\XXXsqlite3.dll) within the osgeo4w-framework for some days. no errors occured.

some additional tests:

(1)

opening the OSGeo for Windows command shell and starting python within:

no renamed C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll

C:\tmp\test>python
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.version
'2.6.0'
>>> sqlite3.sqlite_version
'3.6.21'
>>>

renamed C:\OSGeo4W\apps\Python27\DLLs\XXXsqlite3.dll

C:\tmp\test>python
Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3.version
'2.6.0'
>>> sqlite3.sqlite_version
'3.7.10'
>>>

(2)

a connection to a sqlite database in C:\tmp\test\osgeo4wpythontest.db works

(3)

all examples in ​http://docs.python.org/2.7/library/sqlite3.html with using a renamed C:\OSGeo4W\apps\Python27\DLLs\XXXsqlite3.dll are working.

removing the DLL from the python package and introducing a dependency to sqlite3 is easy.

so it seems this would be way to go?

Helmut

[neteler]

Tried with winGRASS7.svn nightly built:

Renaming:

C:\Programs\GRASS GIS 7.0.svn\Python27\DLLs\sqlite3.dll

to

C:\Programs\GRASS GIS 7.0.svn\Python27\DLLs\XXXsqlite3.dll

solves the problem. Hence we need to get rid of Python27\DLLs\sqlite3.dll in OSGeo4W.

[martinl]

Replying to hellik:

I've tested a renamed sqlite3.dll (C:\OSGeo4W\apps\Python27\DLLs\XXXsqlite3.dll) within the osgeo4w-framework for some days. no errors occured.

so could be SQLite DLL library removed from the python package? It would be really nice to get rid of the problem...

[jef]

Replying to martinl:

so could be SQLite DLL library removed from the python package? It would be really nice to get rid of the problem...

done. The testing area is updated, please test (osgeo4w-setup -t or setup-test.bat)

[hellik]

Replying to jef:

Replying to martinl:

so could be SQLite DLL library removed from the python package? It would be really nice to get rid of the problem...

done. The testing area is updated, please test (osgeo4w-setup -t or setup-test.bat)

complete fresh test-install by setup-test.bat in a new folder C:\OSGeo4Wtest, only wingrass7svn and dependencies installed.

some testing (always in the OSGeo for Windows command shell and the Minimal SYStem):

testsqlite.py

import sys
import sqlite3
print sys.executable
b = sqlite3.version
print b
c = sqlite3.sqlite_version
print c

myricaria@MYRICARIA-HP /c/tmp/test
$ python testsqlite.py
C:\OSGeo4Wtest\bin\python.exe
2.6.0
3.7.10

test-shapefile

$ ogrinfo -al test.shp
INFO: Open of `test.shp'
      using driver `ESRI Shapefile' successful.

Layer name: test
Geometry: Point
Feature Count: 3
Extent: (11.360236, 47.562036) - (12.456152, 47.884962)
Layer SRS WKT:
GEOGCS["GCS_WGS_1984",
    DATUM["WGS_1984",
        SPHEROID["WGS_84",6378137.0,298.257223563]],
    PRIMEM["Greenwich",0.0],
    UNIT["Degree",0.0174532925199433]]
Id: Integer (6.0)
pname: String (3.0)
OGRFeature(test):0
  Id (Integer) = 0
  pname (String) = a
  POINT (11.360236291910875 47.884962359602177)

OGRFeature(test):1
  Id (Integer) = 0
  pname (String) = b
  POINT (12.456151953403253 47.882419631849288)

OGRFeature(test):2
  Id (Integer) = 0
  pname (String) = c
  POINT (11.812841831923969 47.562035934986092)

ogr2ogr test-shapefile to a sqlite-db

myricaria@MYRICARIA-HP /c/tmp/test
$ ogr2ogr -f "SQLite" shape2sqlite.db test.shp

myricaria@MYRICARIA-HP /c/tmp/test
$ ogrinfo -al shape2sqlite.db
INFO: Open of `shape2sqlite.db'
      using driver `SQLite' successful.

Layer name: test
Geometry: Point
Feature Count: 3
Extent: (11.360236, 47.562036) - (12.456152, 47.884962)
Layer SRS WKT:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
FID Column = OGC_FID
Geometry Column = GEOMETRY
id: Integer (0.0)
pname: String (0.0)
OGRFeature(test):1
  id (Integer) = 0
  pname (String) = a
  POINT (11.360236291910875 47.884962359602177)

OGRFeature(test):2
  id (Integer) = 0
  pname (String) = b
  POINT (12.456151953403253 47.882419631849288)

OGRFeature(test):3
  id (Integer) = 0
  pname (String) = c
  POINT (11.812841831923969 47.562035934986092)

connect2db.py

import sqlite3
conn = sqlite3.connect('shape2sqlite.db')

c = conn.cursor()

# Create table
c.execute('''CREATE TABLE stocks
             (date text, trans text, symbol text, qty real, price real)''')

# Insert a row of data
c.execute("INSERT INTO stocks VALUES ('2006-01-05','BUY','RHAT',100,35.14)")

# Save (commit) the changes
conn.commit()

# We can also close the connection if we are done with it.
# Just be sure any changes have been committed or they will be lost.
conn.close()

sometest.py

import sqlite3
conn = sqlite3.connect('shape2sqlite.db')
c = conn.cursor()
# Do this
t = ('RHAT',)
c.execute('SELECT * FROM stocks WHERE symbol=?', t)
print c.fetchone()

# Larger example that inserts many records at a time
purchases = [('2006-03-28', 'BUY', 'IBM', 1000, 45.00),
             ('2006-04-05', 'BUY', 'MSFT', 1000, 72.00),
             ('2006-04-06', 'SELL', 'IBM', 500, 53.00),
            ]
c.executemany('INSERT INTO stocks VALUES (?,?,?,?,?)', purchases)

for row in c.execute('SELECT * FROM stocks ORDER BY price'):
        print row

myricaria@MYRICARIA-HP /c/tmp/test
$ python sometest.py
(u'2006-01-05', u'BUY', u'RHAT', 100.0, 35.14)
(u'2006-01-05', u'BUY', u'RHAT', 100.0, 35.14)
(u'2006-03-28', u'BUY', u'IBM', 1000.0, 45.0)
(u'2006-04-06', u'SELL', u'IBM', 500.0, 53.0)
(u'2006-04-05', u'BUY', u'MSFT', 1000.0, 72.0)

osgeo4w-wingrass7svn starts without any problem

Helmut

[hellik]

Replying to jef:

status changed from new to closed resolution set to fixed

thanks for repackaging

Helmut