Sean,

> Your questions strikes me a little like "how many faries can you fit on
> the head of a pin".

Tee hee hee...

> That being said...
>
> How many rows are your talking about processing?

This isn't a bulk thing. It's shifting more of the user workflow into stored
procedures that will make use of tables for what otherwise would be in
volatile memory on the client as the user does their thing.

The GUI won't be all that pretty but these are apps for government workers
who don't expect things to be rosy. So many of our applications follow the
same basic format and flow that I am looking at writing a generic system of
forms and wizards to move them through qualifying, receiving, scanning,
keying and proofing the information that we process.

All of our departments are currently separated out and they all have custom
apps for their various functions but soon we will be changing locations and
all users will work with all systems. So, naturally, in order to make a nice
uniform interface, I want to try and genericize it all and make it much
easier to program and maintain by moving more stuff to the server.

In short, making a generic workflow processing system will require using
table space as volatile memory for each document to be processed. This will
result in a lot of inserts and deletes in those respective work tables. Some
of it will actually accumulate as workflow history but not all.

> Average size of row data?

200-1200 bytes

> How many indexes would be created for the tables?

probably only one or two.

> Are you going to be using External Tables or Query to load rows?

No loading of data. Just day to day stuff by about 5-40 users.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com