search

nakijun / fdotoolbox

Automatically exported from code.google.com/p/fdotoolbox
0 stars 0 forks source link

CRS-related tables/columns missing? #67

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
It seems that there's a column or two missing from the SQLLite storage. 
Please see attached screenshot.

Original issue reported on code.google.com by LivelyTe...@gmail.com on 29 Jul 2008 at 6:56

Attachments:

GoogleCodeExporter commented 9 years ago 
what steps did you take to cause this error? The sqlite database should already 
have
the table/columns defined. There is no 'create table' statement anywhere in the
code-base.

Original comment by jumpinja...@gmail.com on 29 Jul 2008 at 8:54

GoogleCodeExporter commented 9 years ago 
I've used Trunk source to build binaries. Above exception gets thrown as I try 
to 
Edit data store coordinate system. Should I build from the latest Branch 
instead?

Original comment by LivelyTe...@gmail.com on 29 Jul 2008 at 9:17

GoogleCodeExporter commented 9 years ago 
There should be a cscatalog.sqlite databse in the FdoToolbox.Core directory

This database gets copied to out\[Debug|Release] on every build

Can you open this database with any sqlite editor (eg.
http://sqliteadmin.orbmu2k.de/) and see if there is a table called 
"Projections"?

Original comment by jumpinja...@gmail.com on 29 Jul 2008 at 10:04

GoogleCodeExporter commented 9 years ago 
If you follow these steps:

1) Right-click Connection
2) Select Manage spatial contexts option
3) Click on Edit button
4) Click on Load CS button

FDO Toolbox throws previously described exception.

Original comment by LivelyTe...@gmail.com on 31 Jul 2008 at 9:22

GoogleCodeExporter commented 9 years ago 
I get a Coordinate System Picker with an empty grid (expected behaviour for an 
empty
database) instead of the specified exception. Are you sure svn is not reporting
cscatalog.sqlite as being modified?

Original comment by jumpinja...@gmail.com on 31 Jul 2008 at 10:39

GoogleCodeExporter commented 9 years ago 
Strange... I tried using build_release.bat on both \Trunk and latest \Branch 
version 
and everything works fine except for that one. There is a cscatalog.sqlite (3 
Kb) in 
\out\Release folder, as expected (attached).

Original comment by LivelyTe...@gmail.com on 31 Jul 2008 at 10:48

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm getting the same error from Trunk.  The database exists, and the (empty) 
table 
Projections exists within it.

Original comment by ja...@jasonbirch.com on 31 Jul 2008 at 9:29

GoogleCodeExporter commented 9 years ago 
My dev environment could possibly be playing a factor. I'll need to setup a 
"pure"
environment to see if that makes a difference.

Original comment by jumpinja...@gmail.com on 31 Jul 2008 at 10:59

GoogleCodeExporter commented 9 years ago 
I was able to reproduce this on a "pure" system. I have committed what I 
believe to
be the fix into the trunk. Please svn update and build your working copy and 
see if
this is now resolved. Thanks.

Original comment by jumpinja...@gmail.com on 1 Aug 2008 at 12:28

GoogleCodeExporter commented 9 years ago 
Thanks Jackie, works like a charm now :-)

Original comment by LivelyTe...@gmail.com on 1 Aug 2008 at 7:14

GoogleCodeExporter commented 9 years ago 
Then we'll say fixed in r226. Basically the problem was twofold with SQLite 
ADO.net
driver.

1) It didn't like the fact that I had a non-absolute database path in my SQLite
connection string.

2) As a result, SQLite would create a *blank* database (hence those errors about
missing tables/columns). This default behaviour (???) can be changed by specify
FailIfEmpty=true as part of the connection string, so if it can't find
cscatalog.sqlite (it should find it) it will now throw FileNotFoundException 
instead
of creating an empty databse.

Original comment by jumpinja...@gmail.com on 1 Aug 2008 at 8:58

GoogleCodeExporter commented 9 years ago 
I've also noticed this funny behavior (2) but I though it's "by design" :-)

Original comment by LivelyTe...@gmail.com on 1 Aug 2008 at 9:00