Is SQL Server with Access as a front end an option for you? Just an idea. There aren't any desktop databases that I know of that will handle volumes of the 2Gb+ size.
-----Original Message----- From: Rob Whiteley [mailto:row@;lihir.com.pg] Sent: Tuesday, October 22, 2002 4:11 PM To: MapInfo-L Subject: RE: MI-L Large Access database build problems Hi Bill, Warren is correct, Ms Access 2002 can handle up to 2Gb of database sizes (see "Access specifications" in help). In practise, the limit is unfortunately more like 1Gb. Cheers, Rob -----Original Message----- From: Warren Vick, Europa Technologies Ltd. [mailto:wvick@;europa-tech.com] Sent: Wednesday, 23 October 2002 8:47 AM To: Bill Thoen; MapInfo-L 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 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 3707 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 3710