Aloha End of Day and Winhook

[qsrsf]

Two EOD questions:
How do I set up the winhook to run the EOD at a set time every day?

&

More importantly I am only open from M-F, how do I make the above winhook run EOD three times on friday so that the systems are ready for Monday morning? (Is there an alternate flag somewere that says the business is only open from M-F and to automatically make DOB Monday when run on Friday?)


THANK YOU!

 

[AkamaiAloha2]

Winhook will run after EOD is fired. Whatever you're trying to execute, don't make the mistake of putting the path in with the file--Aloha will already be assuming it's in the BIN directory.

I am not sure I understand the second part. Your system should still be doing an EOD on the days your closed (both Satuday and Sunday) and that same file should be called after EOD.

Winhook works well enough--but for complicated demands (or in the event that I don't understand the above question) you have a lot more flexibility with the Windows Task Scheduler.

 

[AkamaiAloha2]

A quick thought, after I re-read your post.

>>How do I set up the winhook to run the EOD at a set time every day?


I am sure if this is a typo, but your EOD should be a setup in the event scheduler. When EOD is done, if there is anything in the winhook path, it will fire then. But it plays no formal role in the EOD process, other than your special requirements outside of the Aloha system, in most cases.

 

[posrescue]

Right on Akamai.
One addition in regards to Winhook. Winhook fires after EOD starts but before it finishes. If the batch file(s) or script(s) that are called by Winhook fail to complete your EOD will usually fail to complete as well. (ie-dated subdirectory is created and populated but prt and trans logs still remain in data, the date of business does not change and the EOD marker file remains) This does not always occure but can and should be motivation to make sure your batch files or scripts are flawless.

 

[qsrsf]

Thanks on the EOD, Winhook, and events.

How do I force Aloha to skip Saturday and Sunday then (when we are closed)? What I have been doing is just forcing two more EOD's on Friday evening.

Also, related but not really, when I was setting up and testing I had a bunch of junk data for a few days. The consenus here was to just delete the dated sub directories and the data would be gone, but in reports and some other places those old dates (pre open) still show and more importantly when the grind happens it takes a LONG time when it gets to 'start historical sales'. My guess is that it can't find the dated subdirectories and hangs for a while until it moves on. How do I fully clear the old data and references out?

Thanks!!!

 

[themaj]

As for your pre-opening data; the safest method is to rename your 'pre-opening' dated Subdirs as in 20060519 > 2006051_9. Aloha cannot, willnot recognize this subdir.

Then rename your SUM dir as in SUM_X.
Then create a new SUM dir.

A question I have for you is why Force EOD when Aloha will run them anyway? If you're saving power by turning off the system:
A) your not saving any power really if you just turn off the monitor.
B) rebooting your system is the time when a computer is most vulnerable to problems.

Just leave the Master and Fileserver running and that will solve the issues.

Any comments from others?

 

[themaj]

In regards to winhook and when it fires up. If it's starting before EOD completes and causing a problem, the easiest fix is to write your batch file to wait until EOD concludes by watching for the DONE30 file creation. An even safer option method would be to sit in the background waiting for the grind to complete by checking for GNDDBF30.XXX

 

[qsrsf]

As far as running EOD manually, I had no good reason really, I just liked to see it done before I left so I was assured there would be no problems when staff arrived and began clocking in the next morning at 6AM.

Other issues from above:
The SUM directory doesn't have any data in it, so I don't see why renaming and creating new would do anything. The data from the testing data is gone, but in the reports those old dates still show up and I believe that my grind is hanging. If they aren't affecting the grind I really don't care about them...

Here is the a peice of the grind slow-down.

The grind DEBOUT shows this:
...
May 22, 19:02:38 [2824] DAO Version 3.5
May 22, 19:08:36 [2824] UpdateRecord: no record matching DateOfBusiness = '#05/22/2006#' AND FKStoreId = '1' AND FKRegionId = '1' AND FKOccasionId = '1' AND FKRevenueId = '1' AND FKItemId = '901' AND IntervalStart = '#05/22/2006 12:15:00 AM#' AND IntervalEnd = '#05/22/2006 12:29:59 AM#'
May 22, 19:08:37 [2824] UpdateRecord on HstItemSalesByInterval failed

The interesting peice is the 6 minute hang between the entries. My initial thought was that it had to do with the dated sub dirs I deleted because the grindqs simply says "start historical data" and sits. The log shows something else.

Any ideas or have I thougholy confused everyone?

THANKS

 

[themaj]

Sounds like you're using the SQL which I can't really help you with it but I'll look into it.
If you're using the DBF version do the pre-opening dated subdirs still exist and are just empty? If so delete or rename them.

 

[qsrsf]

I am using the SQL version, which raises another question, can I do a new install and switch back to the DBF version? What are the ramifications of this?



Thanks

 

[posrescue]

SQL - You can go off of SQL mode if you wish with no problem. In the olden days when file corruption in the .dbf files was pretty common I used to go to SQL mode to recreate the .dbf files and clean the corruption then go right back to "normal" mode...

Dated Subdirectories - You don't want dataed subdirectories that are not populated. If the contents of these folders have been deleted rename or remove the folders themselves.

 

[qsrsf]

To change back from SQL to DBF, just copy out my data dir's and do a new install from CD?

Any other suggestions on the old data (folders are completely gone but when I run reports those old dates are still available in the pull downs) or the error from the DEBOUT above?

Thanks

 

[posrescue]

I would not reinstall as there could be data loss. Perform the following to conver back to dbf mode.

To convert from RDB-mode to dbf-mode, you must edit the SQLMODE system environment variable, edit the SQL.ini, and remove the SQLMODE command-line variables from the Windows registry.

-Stop Control Server (CtlSvr.exe in services)

-Edit the Windows system environment variables and remove the SQLMODE system environment variable.

-Edit the SQL.ini located in the Aloha SQL folder and change the RDBTYPE value to Unsupported (for example, RDBTYPE=Unsupported).

-Remove the SQLMODE command-line variable from the Control Server command-line in the Windows Registry.

--HKEY_CLASSES_ROOT\AppId\{81DD90A1-CF22-11D1-A84F-0080AD1C6910}

-Restart Windows, which also restarts Control Server. You should leave your RDB engine installed, along with the Aloha RDB, for several days until you have determined that all of the data is present.