Mark,

I don't have a complete answer for you without testing, but here are a few comments.

>Possible speedup: Copy system, zap data files in the copy, update this empty system. Then, APPEND FROM existing data.

Instead of copy and zap, just COPY STRUCTURE (WITH CDX or not depending upon test). If the tables are part of a DBC you can also use GenDBC to create a PRG which will create the entire DBC.

>-- Would I save more time if I APPENDED without reindexing and then created fresh .CDXs afterwards? (I assume creating them during the APPEND will cause some thrashing and slow things down.) Any gotchas to doing this?

I think the indexes will be smaller and better if you create the CDX after the import, but I'm not sure it'll be faster since you'll have to access the data all over again. But I'm not sure.

>-- Recommendations on how to optimize the disks and controllers -- should I use one controller per drive, set the drives up as master/slave or "separate but equal", etc. Thanx!!

The data is going to have to go to the local processor regardless unless you're on a server with an admin utility to copy between volumns. As for the rest, if you're going to mess with multiple controllers, etc. I'd spend the money on fast SCSI drives and a top-of-the-line RAID controller. That'll do more for speed then trying to split it up.

All of that said, on a fairly slow Novell server on a 100BT network with a reasonable speed array I can pack and reindex multiple tables totalling over 4GB in 4-5hrs. I suspect you speed problem has to do with a slow network (10BT?) or not having abundent free space.

But even if you copy the files to a local drive, aren't you copying the files twice over a network? A Pack, copy or Alter table is basically 1 copy. Why not run each file at the same time on differn't machines? The network speed is way slower than drive speed.

HTH