You are correct to start with set of books that you know thoroughly.
If you have a small set of books under 50 Mb, that would be good to start with.

When converting books larger than 50 Mb, you should use “transaction compression”.

We recommend that you set the “Begin Full Detail” date 12 months back from your DOS books fiscal year end.

With “transaction compression” all your data is still transferred to NV2. Data older than the “Begin Full Detail” date will be summarized monthly . This summarized data can be found in the “Compressed Transactions Journal”.

Our recommendation is to “decompress” one month of transactions (i.e. the last row of the journal – and work backwards) each week night and a block of two or three transactions each weekend. This way, while the computer would normally be idle, you can use the time to systematically decompress the “compressed data” in NV2.

Our new html manual is searchable, please check the references made to “compress” and “decompress”.

Regarding NV2 performance in general, you are correct to note that in the beginning NV1 was a resource hungry program, but it got faster and faster as computers got faster, and Q.W. Page added performance enhancements. The same will be true with NV2.

The simple explanation for NV2’s current performance can be summarized as follows:

1) NV2 is based on an entirely new database technology that permits real-time, multi-user access and system-wide database updating, without the need for batches, or file/record locking.

2) All data values in NV2 are “variable length”. There is a performance price to pay for index keys that can be any length.

3) Account ledgers in NV1 were only kept for posting accounts. Total accounts stored only a summary of activity. This was a major restriction, and it created all sorts of problems for users with odd reporting periods, changing fiscal year ends, and so on. In NV2 all transactions “ripple” to all total accounts. This means you can view the ledger detail of total accounts, but, more importantly, you can report on any period (e.g. monthly for prior years without limit, weekly, daily, etc.)

Q.W. Page included transaction compression/decompression to address the challenge of importing years of activity, into books with deep and complicated total to structures. For example, we have seen a set of books where the average posting affected 95 total accounts. In an NV2 conversion of this set of books, each posting created approximately 1,000 ledger index entries. Without transaction compression, this set of books may have taken a week or two, or longer, to import. With compression (set prior to the current fiscal year begin), the books converted overnight or over a weekend.

NOTE: You can find diagnostics on your total to structure in the file NV1_NV2.totalsinfo.
This file is created (in the directory the books are in) after all the total to’s are connected, and before transactions are imported. You can open NV1_NV2.totalsinfo with a word processor. If your “AverageTotaltos” is greater than 20, you have a reasonably complicated set of books and the import could take a while without transaction compression.

Several promising performance enhancing strategies are in the works. NV2 will only get faster.

Q.W. Page