Hi All,
Can anybody shed any light in this……
We performed a complete Navision Backup, built an empty database and ran a Navision Restore.
The following 2 tables then looked like this....
Table
G/L Entry
No Of Recs 2,432,752
Record Size 590
Size 1,400,784
Optimization 97.1
Table
Cust Ledger
No Of Recs 2,214,314
Record Size 2,144
Size 4,635,608
Optimization 97.3
We then ran 4 main DD and Sales HP posting runs. (Our own routines).
This added a total of 59,234 records to G/L and 59,126 to Cust Ledger.
Tables then looked like this....
Table
G/L Entry
No Of Recs 2,491,986
Record Size 596
Size 1,450,296
Optimization 95.9
Table
Cust Ledger
No Of Recs 2,273,440
Record Size 2,714
Size 6,024,688
Optimization 76.9
G/L has increased by a respectable 49mb, Cust ledger by an astonishing 1,380mb.
Even allowing for the fact that Cust Ledger record size is five times larger this does not in any way explain why the increase in Cust Ledger table size is so dramatic.
After the first DD run G/L went up by just under 11mb, Cust Ledger 1,232mb. Subsequent runs saw G/L increase by a similar amount with Cust Ledger incrementing by 31, 14 and 15mb.
After first Sales HP run G/L went up by just under 2mb and Cust Ledger 84mb. Subsequent runs saw G/L increase by a similar amount with Cust Ledger incrementing by 5, 4 and 4mb.
Both have ‘Entry Number’ as primary key, so what design ‘feature’ is causing this to happen? It has to be down to the design as the decrease in optimisation percentage is huge (20.4%).
As we all know, during the first run, it is adding huge amounts of space after each record is inserted.
How is it calculating how much space to allocate?
As there is so much space, why on subsequent runs does the table size increase at all?
Thanks in Advance
Robin
0