in which case
look at the table
find how many rows are in it
go through the table defintion and count the number of bytes
which is a bit of a pain.
if you want to go down the maths route
you need a list of each datatype this gives the gruesome details
bear in mind that Access always reserves some space for itself, and for indexes, forms reports etc...
it also needs some working space to allow for inserts and so on. you can reclaim this working space by doing a compact and repair occasionally
so I'd take your data calculation multiply it by the number of rows expected, then double it.
the space required for forms & reports is largely unquantifiable.. depends on how the number of such items, how complex they are and so on.
Id hazard a guess at low medium & high
say 5Mb for low, 10..15 for medium, 15+ for a high
H'm lets see if theres a problem here
in one app I have around 15 tables with masterfiles / config data in... aomewhere between 10 & 50 records per table, 3 medium sixed tabels around 10....40 rows eachs, and one big FCUK table with 350,000 rows, natch the column definitons mastefiles tables are are tiny, (usually the PK, description & some other stuff around 100 bytes per row), and the monster table is around 800 bytes per row (excluding the memo field)...
simple division isn't going to work there.
of course I suppose if you were being cute, and quoting the table size without any data in it then dividing the file size by the number of tables would be a reasonable proposition. however I can imagine the look on aforesaid boss's face when he comes to whinge that the app has just gobbled up all the spare server disk space and you tell 'em it was n bytes with no data in it.....