DHES

Dale, what does the _rec file do? It grows like crazy. I'm just setting up a demo and on the old laptop I'm using which only has a small h/drive it seems to be growing like mad. It looks as though it holds transaction report data - when you delete it am I right that the program just recreates it again?

What happens if your system only has a very small disk drive which many old PCs of the kind that DHPOS loves frequently do? Is report data lost?

I always tell people they can back up onto a floppy - but wih a huge _rec file that doesn't look to be possible.

If the system does recreate the _rec file (and any others??) what are the MINIMUM files to back up to ensure that no data of any kind is lost?

If you do want to back up onto a floppy are there reports that you should run at the time and files that can then be deleted to make small back ups possible?

The reason for asking these questions is that I prefer to run DHPOS in DOS mode, not Windows, so I don't have the option of eg burning to a CD but I like to have backups that are removed from the main machine for obvious reasons.

Rollerball,

The ???????.REC file contains the record of past sales, the ones you can see when you use option "5. Voids" from the main menu of the POS.EXE program. When you go to the "Sales recording - Voids" feature of the POSCONFG.EXE program you can choose to save the last 0, 10, 100, 1000, or 10,000 sales in the ???????.REC file. Since each transaction saved requires 1960 bytes saving 10,000 sales will require a ???????.REC file 19,600,000 bytes long. However if you choose to save only the last 10 sales then the ????????.REC file will be only 19,600 bytes. If you choose to save more than zero past sales then you are correct that when you erase the ???????.REC file the program will just create a new one so that it can save the sales you requested to save. However it will not grow larger unless you choose to save more of the past sales. The sales will overwrite. For example if you choose to save 100 past sales then transaction 0101 will overwrite transaction 0001.

Some files will grow without limit. As you add customers to the customer info file the ???????.CST file will grow by 410 bytes per customer. Customer sale data increases the ??????.SLS file by 20 bytes per transaction. Of course if you do not track customer info these files will not grow.

If you go to the "Reports" feature and make a "Report A" of sales over time, i.e. more than one day, the program will access the ????????.PS1 file which records the figures from the closing receipt when you close the register. This increases at 1000 bytes per close so if you close the register once every day the file will grow by 365000 bytes per year.

If you archive the journals then 366 journal files will be saved. The lenght of each journal depends on the sales you had that day.

You ask, "What happens if your system only has a very small disk drive which many old PCs of the kind that DHPOS loves frequently do? Is report data lost?" The answer is that you will fill up the disk and no more data can be saved. And this will happen no matter how huge your drive is since there are files that grow without limit. However this could take thousands of years to do depending how huge your drive is.

You also ask, "If the system does recreate the _rec file (and any others??) what are the MINIMUM files to back up to ensure that no data of any kind is lost?" Here is a surprise, my POS program does not create files and save data to them just because it is bored and has nothing else better to do. If you do not backup any file and that file is lost then whatever data it contained will be lost also.

Dale

Thanks for that Dale. So if you delete the _rec file, you do lose the old sales data. What it creates is a new empty _rec file ready for future records to be saved. That makes sense. I had a setting of 10000 which under the circumstances was too much - better to make it something like 100 I guess. I think I maybe need to look at archiving (and saving to an external floppy) journals as a way of keeping actual past transaction records. That will probably be the best way of minimising the amount of 'live' data held in the DHPOS folder.