[GRASS-user] getting from DBF to SQLite

Michael Barton Michael.Barton at asu.edu
Thu Feb 14 07:47:45 PST 2013


This and especially portability is why I argued--unsuccessfully--for a separate sqlite DB for each vector file, even if it is inefficient.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671(SHESC), 480-727-0709 (CSDC)
www:  http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Feb 14, 2013, at 5:55 AM, grass-user-request at lists.osgeo.org<mailto:grass-user-request at lists.osgeo.org> wrote:

From: Hamish <hamish_b at yahoo.com<mailto:hamish_b at yahoo.com>>
Subject: Re: [GRASS-user] getting from DBF to SQLite
Date: February 13, 2013 4:50:15 PM MST
To: GRASS user list <grass-user at lists.osgeo.org<mailto:grass-user at lists.osgeo.org>>


Richard wrote:
Is it is possible to set a single SQLite database
for the entire GRASS GIS database or each mapset requires
its own sqlite db file?

organize your system as you like, but be sure to ask yourself what
happens to portability with 32bit machines and/or filesystems when the overall DB file gets to be larger than 2gb or 4gb in size.
Even per-mapset sqlite DBs worry me a bit for that, not to mention
the damage-fallout from a bad HD sector or accidental `rm` and
ease of moving stuff to another mapset/ system by hand.


Hamish


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130214/8d06ebb7/attachment-0001.html>


More information about the grass-user mailing list