Javier: I've seen Bob's app before, and it's a cool front-end type of form with lots of data for the users to see. The timer updates some of the data on the form. Let me think, if a scheduled task ran an "outside" RBase program, I guess it's possible that that program could dump the display data into a lookup type of table, and could still have a timer on the form that would gather and recalc the display. The form could have a "date last ran" / "date next run" so the user has some feedback on the process. A bit of work, but it would take the form out of the equation, wouldn't it?
Karen -----Original Message----- From: Javier Valencia <[email protected]> To: karentellef <[email protected]> Sent: Mon, Aug 24, 2015 1:01 pm Subject: [RBASE-L] - Re: Button EEP versus Timer EEP Rather than having a form with a timer that is running continuously, wouldn't it be easier to place the code in a small application and run it using the Windows Scheduler? I have an application that runs once a day to import data from another system that kicks in 30 minutes after midnight, does its thing and exists...no need to have a form with a timer running all the time. Just a thought. Javier, Javier Valencia, PE O: 913-829-0888 H: 913-397-9605 C: 913-915-3137 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bob Thompson Sent: Monday, August 24, 2015 12:24 PM To: [email protected] Subject: [RBASE-L] - Re: Button EEP versus Timer EEP No. The compiled app simply starts the external form. Then the form timer runs the CFA at designated times. There is a office button on the external form that had the exact same property command as the timer eep to call the CFA. When the timer calls the CFA, the code starts and process much of the code, but then stops on the same record each time. By stopping, I mean it stops processing the CFA and returns control back to the external form. I can then click the office button and the same CFA will run complete. Thus my thoughts that it is not a memory issue. Bob Thompson LaPorte, IN 219-363-7441 Sent from my iPod On Aug 24, 2015, at 11:41 AM, Dan Goldberg <[email protected]> wrote: > So you are launching a compiled app from a form of another compiled app? > > Dan Goldberg > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Bob Thompson > Sent: Monday, August 24, 2015 9:13 AM > To: Dan Goldberg > Subject: [RBASE-L] - Re: Button EEP versus Timer EEP > > I can try the memory flush, but I do not think that is it. This is a compiled app. When the CFA stops, it returns to the external form. I can then click a button eep that calls the same CFA and it runs fine. I would think a memory issue would linger without an exit or flush. > > As far as speed, I am very satisfied. We previously used a commercial third party MRP program. It would not do exactly what we needed and it took well over 4 hours to run. So now we have the exact capability we need and in 1/4 the time! > > Thanks, > > Bob Thompson > LaPorte, IN > 219-363-7441 > > Sent from my iPod > > On Aug 24, 2015, at 10:20 AM, Dan Goldberg <[email protected]> wrote: > >> You might try to flush the memory after it runs to see if that helps. >> >> PROPERTY APPLICATION FLUSHMEM 'TRUE' >> >> Just a tip, you might trying to declare your cursors before the while loops to speed it up. >> >> Dan Goldberg >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of Bob Thompson >> Sent: Monday, August 24, 2015 6:32 AM >> To: Dan Goldberg >> Subject: [RBASE-L] - Re: Button EEP versus Timer EEP >> >> Thanks to Karen and Mike for the responses. >> >> The code stops on record 1083. >> >> There is approx. 400 lines of code that executes properly before the process stops. I have bee unable to determine the exact code line that it stops on as TRACE or running it outside the timer does not exhibit the problem. The code does stop inside a structure of: >> >> Declare C1 >> While >> Delare C2 >> While >> While >> While >> Stopping inside the last while loop. >> >> I have checked for improper breaks, goto's, etc. (It runs fine outside the timer. ) >> >> This is a MRP program running for 1000+ items with multiple nested component levels for 14 inventory locations. It is a significant chunk of code logic. It takes about an hour to run, which makes multiple test runs somewhat time consuming. > >
