how to regenerate reports after changing categories, job codes, etc.

SOLUTION OVERVIEW: you must which database files need to be copied into dated sub-directories. I have a script to copy database files into a year's worth of sub-directories. in certain situations this saves a lot of boring, error prone work, but it's not really user-friendly, at all, ask me for a copy if you wish.

BACKGROUND:
When you update data in aloha, for example, changing an item name but keeping the item number, changing a job code to printable, changing tax categories, etc., the changes do not propagate to older data. This is by design, each day of business has a complete copy of the database as it existed that day, and this version of the database is used whenever you report.

NOTE: do not do this during business hours!

SOLUTION
STEP 1: identify the database files. the simplest way is to use the date modified field plus some common sense. Make the changes in aloha manager you want reflected in your historical reports, then on your server look at [aloha directory]/newdata and see which files ending in .dbf have been modified very recently.

The files are usually clearly named, if you make a change to job codes, it's in job.dbf, changes to items are in item.dbf, etc.

STEP 2: back up. stop the control service (start: run: type services.msc, locate ctlsvr, right click, choose stop). Backup all the dated subs you intend to modify. I strongly suggest you zip them up using a program like 7-zip, they compact very well and the time you spend zipping will be made up in copy-time savings.

STEP 3: copy the selected .dbf files, and only the .dbf files (no .cdx or .tdx or .beer, etc.) from newdata into the dated subs you want to report on. You can do this by hand, or use the script below to automate copying into a year of dated subs.

STEP 3b - AUTOMATING THE COPY
I wrote a script to automate copying .dbf files into a year of subdirectories (especially useful if you want to replace the original .dbf files afterwards).

This script is for internal use, it's not very... properly done. I could clean it up a bit if anyone wants a copy, let me know.

STEP 4: Restart Control server, run reports, stop control server again and restore the backed-up dated subs to return your historical data to its original form (if you wish). start ctlsvr once again.