main logo
Subject: Re: Splitting a big-honkin' table
Author: Dan Covill
Posted: 2003/04/30 16:08:00
 
View Entire Thread
New Search


Ken:

You didn't say specifically, but I infer that you're making a vertical
split - some fields in File1 and the rest (plus the key) in File2.

If so, there's a much simpler solution:
use OldFile
copy to FILE1 fields KeyField, Field1, Field2, Field3, .....
copy to FILE2 fields KeyField, Field101, Field102, Field103, .....

Dan Covill


At 11:08 04/30/03 -0500, Ken Kixmoeller (j/s) wrote:

>I have a table (DBF) in a client application nearing the dreaded 2GB
>limit. We discussed all of the options, the *they* decided to go with the
>old-fashioned fix and split the table.
>
>I have already fixed everything that needs to be fixed to implement this,
>now I just have to actually split it. To populate the "second" table, the
>best way (based on time) was to scan the table and scatter/gather into the
>second one.
>
>I am experimenting with several techniques to alter the first table:
>
>1. ALTER TABLE <MyTable> DROP COLUMN <thisone> drop column <thatone> etc.
>
> I get an error: "Unable to create temporary work files." This in spite
> of running it on a local machine (the client will run it over a network)
> which has over 10 GB free on the drive to which I direct temp files.
>
>2. SQL Select into a table or Cursor. Delete or rename the original table.
>Rename the table/Cursor to the original name and rebuild the indexes.
>
> I have been running a test of this. So far, the SQL select alone has
> been running over 1 hour (on the same machine).
>
>3. Copying the table to another table, splitting the table, (removing the
>indexes) and appending it back into the 2 tables (and rebuilding the indexes).
>
>4. ??? Is there another way I haven't considered?





 
©2003 Dan Covill
<-- Prior Message New Search Next Message -->