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

Reply via email to