[Anonymous]

is it possible to copy the previous year’s books of account using a different file name for a different period and cancel the entries to the journal, disbursement and cash receipts books to make a new set of books for the current year in nv2? we did this in nv1 wherein we restore or copy the previous years books which were saved in the diskettes and erase the entries made for the previous year. this way we won’t have to encode all the accounts all over again.
if so, is this also applicable to converted books of account (from nv1 to nv2)?
how do we do this.
thanks.

[BHalpin]

In my NewViews career I have run across a small minority of (DOS NewViews) users that do this – and I have never really understood why. When I ask, they usually don’t know either – they are just doing what someone did before them, and it’s been going on for years and years. (And, quite often they don’t know about making a template of their existing books and creating a new set based on the template. That makes the job a *lot* easier.)

Some believe you have to do this, but the only reason this could be true is if your books grow to 512 megabytes in a year (which is pretty rare.) Others don’t like to see all the old transactions in their accounts – and that is a subjective reason which I can’t argue with. Then there are those who were never shown how to simply set the Begin and End dates on their Income Statement (and related reports) to the new year. They truly believed that you had to start a new set of books every year and were simply amazed to find out that you didn’t. (The same thing applies to ‘closing the books’ – but that’s another discussion.)

So, now to NV2.

Yes, it would be possible to copy the database files to a new directory and then delete all of the journal entries. Here are the pros and cons:

– Pro: It would be easy. While I haven’t tried it, it would (should) be simple to click on the “root” Journal and then block all journal entries and do Block Delete. This would destroy EVERY posting in the books in one operation (And it would be a lot simpler than trying to do it in NV1 by the way, where you would have to go to possibly hundreds of places to delete transactions.)

– Con: The audit trail. The audit trail would contain a record of all the deletions on top of all the create operations that were there to start with. There is (presently) no way to ‘clean out’ the audit trail so you would be stuck with all those entries.

– Con: Time required. This is totally dependant on the speed of your system, the depth of your total-tos, the number of transactions, etc. Suffice to say the mass delete could take a long time.

I’m willing to bet that QW will at some point release a utility for NV2 to make ‘cloning’ a set of books a routine matter – but it is not here today.

I’m curious: What is your reason for starting a new set each year?

Bob

[Anonymous]

for NV1 i made a new set of books every year to avoid the use of so many diskettes as back up for the file. for the first 2 yrs of using NV1 i used 10 or more diskettes, but when i tried starting with a new set on the 3rd yr, i ended up using only 8 diskettes at the end of the year to back up my file.
i don’t know if i can do this with my books of account from CY2004-2006 which originally was done using NV1 but were converted to NV2. is it possible?
thanks

[Anonymous]

for NV1 i made a new set of books every year to avoid the use of so many diskettes as back up for the file. for the first 2 yrs of using NV1 i used 10 or more diskettes, but when i tried starting with a new set on the 3rd yr, i ended up using only 8 diskettes at the end of the year to back up my file.
i don’t know if i can do this with my books of account from CY2004-2006 which originally was done using NV1 but were converted to NV2. is it possible?
thanks

[BHalpin]

Right off the bat – do not, I repeat, do not rely on diskettes for backups.

Over the years QW Support has had to rescue countless users who backed up on diskettes but then found them unusable when the need came to do a restore. (It was actually one of the most interesting parts of the job.)

Here is why:

Under Windows, a program writing to a diskette has absolutely no way of verifying that the data it asked to be written is in fact on the diskette and readable. The “write verify” option that DOS programs relied on before Windows is totally unreliable – and here is an example: I’ve copied a file to a diskette and then taken the diskette to another machine and tried to copy it from the diskette – and I get a read error on the diskette. In fact, I get a read error no matter what machine I try the diskette in. I go back to the original machine and do the copy again; no problem reported. If I immediately use the command-line command COMP to compare the original file to the copy on the diskette it reports the files are identical – BUT – the diskette light never comes on during the compare. This tells me that COMP is being fooled by Windows who has cached a copy of the original file in memory during the copy, and COMP is being fed the cached copy to compare to – not the copy on the diskette. If I pop the diskette out and then back in and do the COMP again I get a read error because there is in fact a bad sector on the diskette, and popping the diskette out caused Windows to discard the cached copy and actually do a proper read of the diskette to perform the compare.

That was long-winded – but it’s really important stuff.

The bottom line is this: DO NOT TRUST DISKETTES FOR BACKUPS. At QW, we became pretty good at predicting that with each additional diskette in a backup set the chances of being able to succesfully restore from those disks went down by 10%. So, if you backup took 10 diskettes, our prediction would be that your chance of restoring from them is zero – and we were usually right.

Another example: I recently bought a 1 Gb USB drive to replace my trusty old 256 Mb one. Guess what? I got stung twice by copying data to the drive and going to a client’s office and finding the data on the drive was corrupted. I returned the drive and got a replacement and it works fine. Correction: (and important distinction) It has not failed YET.

So, what do you trust your backups to? The answer is nothing – you can’t trust any media to be readable when disaster strikes. All you can do is use multiple backup methods/media (CD, USB drive, tape, etc.) to make sure you are covered. So, backup onto USB drives (plural) – they are cheap and pretty reliable. Also, do backups on CD. Backup to another machine in the office. Mix and match these methods and you reduce your chances of disaster to near zero.

---

Now, with that diatribe over I’ll address your reply above. If you stop using diskettes for backup and move to a method with ‘modern’ speed and capacities, it won’t matter how big your books get, and the need to start fresh books every year is gone.

Bob

[Author]

Posts