|
** IMPORTANT NOTE for users converting to version 2.09 **
Version
2.09 will re-create all workstation and server databases!
|
See Completed folder management and User managed settings for table column layouts for more.
The items listed below are the things that will be lost, and need to be recreated. We understand it will be a significant irritant, but hopefully the new approach to window setup and use will make it worthwhile.
From version 2.09 on, each database is a single file.
In addition, there are no longer any separate recovery files associated with a database. Recovery is now managed without the need for additional files.
Reasons for this change boil down to integrity and user convenience. From time to time, NewViews users were mixing up database files by copying some but not all of the files associated with a database from one folder to another. This usually occurred when backing up, restoring from a backup copy, or just copying a database to a different folder. Sometimes the database files were copied but recovery files, if any, were omitted.
Although these mistakes resulted in confusion and inconvenience, Q.W.Page has been able to revive all databases on which these mistakes occurred.
Note the following issues related to this change:
- Each NewViews file now has the file type ".nv2".
This is the only restriction. You are free to give a database file any name but NewViews will not attempt to open a file unless it has the type ".nv2". You are also free to use other types for purposes such as backup copies. In this case, to restore from a backup you have to rename it to give it the type ".nv2" before it can be opened.
- Any number of databases can be kept in the same folder.
Because a database is now a single file, and because you can give each file a different name, you can keep any number of databases in the same folder.
- Converted accounting databases are named database.nv2.
You can give any file name to a NewViews database but when you first convert a pre-2.09 accounting database to version 2.09 or later the resulting file is given the name database.nv2 and this file is placed in the same folder as the original database files.
The original database files are first backed up to a sub-folder, as usual during a conversion, and then they are deleted from the original folder. They have been replaced by file database.nv2 in that folder.
After the conversion, solely for convenience, you may want to rename the file from database.nv2 to a more suitable name such as acme.nv2 and optionally move it to another folder such as the NewViews installation folder.
- When converted to version 2.09, workstation and server databases are renamed.
When a workstation database is converted, the resulting file is named workstation.nv2, instead of database.nv2 used for accounting databases. Similarly, when a server database is converted, the resulting file is named server.nv2.
The default workstation and server folders were c:/nv/workstation and c:/nv/server respectively, assuming NewViews was installed in c:/nv. After converting, these databases are in files c:/nv/workstation.nv2 and c:/nv/server.nv2. That is, the default workstation and server databases are moved to the NewViews installation directory.
- The maximum size of a database is 16 terabytes.
Prior to version 2.09, the maximum size of a database was 2 to the power of 64, i.e. about 8 billion gigabytes. From version 2.09 on, the size of a database is limited by the maximum file size that can be managed by the operating system.
For Microsoft Windows this limit depends on the particular file system currently installed. On NTFS, the maximum file size is about 16 terabytes (i.e. 16,384 gigabytes, or 2 to the power of 44). On FAT16 or FAT32, the maximum file size about 4 gigabytes.
See Working with File Systems for more on Microsoft file systems.
We believe the benefits of a single file outweigh this limitation. In any case, previous underlying technology is still in place and can be resurrected in special cases where requirements exceed 16 terabytes, i.e. sixteen thousand gigabytes, for an individual database. It is not expected that such requirements will surface in the near future.
The File>Save All command saves changes to disk for files currently open. If issued anywhere on a workstation, all files you have open on that workstation are saved. If issued anywhere on a server, all files that the server currently has open, i.e. that users have open through that server, are saved.
Although NewViews saves information to disk automatically as work is performed, for efficiency purposes the changes are saved during background processing, i.e. when NewViews is idle. NewViews may not be idle very often when many users are simultaneously making changes in a multi-user environment, and the information lost by a system crash can increase accordingly. The File>Save and File>Save All commands force all changes to disk, ensuring that they will not be lost in the event of a system crash.
The File>Backup command saves the current NewViews file to a backup file that has an automatically generated file name. By default, the backup is created in the same folder as the database, but this default can be overridden.
When errors are detected nvcheck now produces an error file which is a Windows help file of type chm, instead of a flat text error file. The error file is only created and displayed if errors were detected. The error file can be closed and displayed again at any time by double-clicking it in a Windows Explorer.
nvcheck now finds all errors before it exits, and displays an error count as processing proceeds.
Account posting tags offered the ability for accounts to filter tags so that accounts would receive postings only for tags as specified in their posting tags field. This posting tags mechanism was primarily for efficiency. It has been eliminated because it was relatively difficult to understand and this outweighed its benefits.
All postings now ripple all the way up the total-to structure and are not filtered out. If posting tags had been used in a database, the database will be converted automatically to reflect this change.
This template field was added to invoice and statement print templates. It prints the description field taken from the invoice header.
PHONE
This template field added to invoice print templates. It prints the phone number field taken from the invoice header account's address.
This new capability is important and expected to be used a lot. This means database explorers will be exploring deeper hierarchies. The default window setup strategy used prior to version 2.09 had to be changed. Instead of setting up windows for each individual folder, this version sets up windows only once for each type of folder. These windows are then reused each time a folder of the same type is activated.
See the next section for more...
(The theory at the time was that the partner window panes for ledgers, etc., would be focused on different data for different tasks. For example, when exploring Account Setup, the companion window may have been positioned on the address window, and when exploring Invoice Aging the companion window may have been positioned on open invoices.)
In practice, this approach appears to have been overkill. Instead, now only one explorer is created, with several "views" (i.e. different column layouts). The Window>Define Columns command (shortcut <F11>) now supports the management of multiple column layouts.
Several new views of data have been added (they can be found under a window tab or in the window list, or in the View command). For example, account ledgers now support debit/credit split views.
Block copy/paste buffers are stored in a more compact format, and the paste preview windows will operate several times faster.
Microsoft Edit Cut/Copy/Paste are now on shortcuts ^X ^C ^V respectively.
Window>Copy Table Columns and Window>Paste Table Columns commands added for copying a table layout. The only requirement is that both the source table and the destination table must be the same color (type). This feature is useful now, but will really come to life when the advanced interface is released (i.e. the existence, appearance and behaviour of all windows can be user controlled).
Print>Account Ledgers has been upgraded to include new features.
Working on a journal's (pink) table of transactions in order entered is an extremely important feature. You can see a contiguous block of new transactions at the end of the journal and it makes it easier to focus on the work at hand. When transactions move around according to a date or reference sort order, users are easily confused or annoyed. Prior to this version, the only way to sort by order entered was to issue a View>Sorted By>Select Index command and select the /id index. Many users couldn't find this solution on their own.
For these reason, clicking on the line number column title will now sort transactions in the order entered.
Remember that transaction detail items have a line number too, and clicking that column title will sort by the /interactive index (so you can Block>Move>Insert and Block>Move>Append to arrange items in any order).
Remember also that transaction headers do not have an interactive index so block move commands are not supported.