I will seriously suggest PostgreSQL/PostGIS for geometric/geographic data!! (Opensource). check http://postgis.refractions.net
Juanse temuko-Chile ----- Original Message ----- From: Warren Vick, Europa Technologies Ltd. <[EMAIL PROTECTED]> To: Bill Thoen <[EMAIL PROTECTED]>; MapInfo-L <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 7:46 PM Subject: RE: MI-L Large Access database build problems > Hello Bill, > > You may be hitting the file size limit which I believe is 2Gb in Access 2000 > and (I recall) only 1Gb in previous versions. Like MapInfo TAB file sets, > 2Gb does not go very far these days especially as I think Access 2000 uses > Unicode throughout... and two byte characters munch through capacity twice > as fast. Do you have SQL Server, MySQL, Oracle or any other (more) > heavyweight DBMS to try? > > Regards, > Warren Vick > Europa Technologies Ltd. > http://www.europa-tech.com > > -----Original Message----- > From: Bill Thoen [mailto:bthoen@;gisnet.com] > Sent: Tuesday, October 22, 2002 11:23 PM > To: MapInfo-L > Subject: MI-L Large Access database build problems > > > I've got a 4GB set of 70 flat files that I need to build into an > Access table to be fed to MapInfo eventually, and boy, am I > having fun with this project! As much fun as shoving bamboo > slivers under my fingernails! > > I've written the VBA code to import the data, and tested it on > the first 50 records of all 70 tables. It works fine. However, > when I cut it loose to hoover up the whole data set, it does a > few hundred MB of import, and gets through several of the files, > then it mysteriously fails on a record set update (Invalid > argument on the statement 'rs.update' -- rs is my recordset > object.) The import file it choked on appears to be fine, and it > dies on different records but it doesn't quite get through the > first gigabyte. The last time, it fell on its sword on record > #2,192,650 in the 7th file. > > There's still 7GB of free disk space, so I thought maybe the disk > needed a disk defrag to provide a bigger chunk of *contiguous* > disk space. Not a good idea. I probably hosed a small, > replaceable SQL Server database on that disk too. Anybody know > why Access behaved poorly after that? I couldn't run my program > at all (it would die on the tabledefs.append statement while > importing the first file) and now there are tables I can't delete > (it's looking for some tmp file it squirreled away somewhere.) So > I exported the table that holds the definitions for the 70 flat > files, and the VBA code to a new Access database, and deleted the > old corrupted *.mdb file and am running the import code again in > the new one. So far, so good. It's on the 5th file and cruising > past record #260,000. So I'm sure the code is okay. > > But when loading large databases, are there disk conditions I > need to be aware of (besides having enough space), or record > count limits or other hobgoblins? Any advice from anyone who's > walked this trail before? > > > -- > - Bill Thoen > ------------------------------------------------------------ > GISnet, 1401 Walnut St., Suite C, Boulder, CO 80302 > tel: 303-786-9961, fax: 303-443-4856 > mailto:bthoen@;gisnet.com, http://www.gisnet.com/ > ------------------------------------------------------------ > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 3704 > > > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 3705 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/02 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 3706
