Thanks for explaining. I have used Run Select for a lonnnggg time. Way before it was popular, and I have never had it misfire.
----- Original Message ----- From: "Gary Wendike" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Thursday, December 15, 2011 11:13 PM Subject: [RBASE-L] - RE: Printing: compiled vs. uncompiled :I probably didn't give the right impression on this email. It is not to say : that RBase has the problem but sometimes the equipment and programming may : not totally support what you want to do. The issue actually arose when : version 9.0 was first released. I had tried several time to convert to : using this version from V8. I covered most of the issue I was having with : John at RBase and he came up with the solution as listed below. At the : time, I was having problems with the system stopping in the middle of the : scheduled tasks. I had 6 different scheduled task that were to run and have : information ready for our office to operate every morning. The program : would hang with error messages on different tasks on different day. I had : sent the same process to RBase and they ran the task with no problems, no : hang-ups and no crashes. During the time frame, I also had the motherboard : replaced on the server...still had the program hang up. : : After many hours of scrubbing my programs and adopting the process below on : parts of my application, I was able to eliminate any processing hang-ups. : To this day, I do not know what caused the problem(besides myself) but I do : know that I have been running for some time with no hang-ups. Since this : could not be replicated consistently, there was nothing to submit. : : Most of the processes I run during evening or mornings generate a lot of : data. On Sundays, my database grows from 4gig to 6.5gig after processing. : I use a lot of permanent and temporary tables and views in the process. : : So the direction of the email was to provide a more drawn out approach to : same process. For me it worked. : : I still use a lot of RUN SELECT commands in my database. I currently have : 73 different commands in a table that I use for processing. : : Mike, thanks for your input and direction to this list. I always appreciate : your insight. : : Gary : : -----Original Message----- : From: [email protected] [mailto:[email protected]] On Behalf Of Mike Byerley : Sent: Thursday, December 15, 2011 8:36 AM : To: RBASE-L Mailing List : Subject: [RBASE-L] - RE: Printing: compiled vs. uncompiled : : I don't get it Gary... RUN SELECT does just what you did in your workaround. : : It puts the entire string value into a variable and passes it to the RUN : command. : : If you have specific replicable instances of a failure, you should send an : example to RBTI to see what is going on so everyone can benefit. : : : ----- Original Message ----- : From: "Gary Wendike" <[email protected]> : To: "RBASE-L Mailing List" <[email protected]> : Sent: Wednesday, December 14, 2011 11:00 PM : Subject: [RBASE-L] - RE: Printing: compiled vs. uncompiled : : ::I tried to use the RUN SELECT for everything I could in my application. :: However, I have found there sometimes is a limit to how a program will :: operate using the run select. In some cases I have had to do use another :: method to run the command. Where the RUN SELECT had problems with :: executing, the following is general process I have used to replace the RUN :: SELECT and have had no problems in running the command. :: :: :: :: Select command into variable from commandfile where commandid = idnumber :: :: Output command.rmd :: :: Write variable :: :: Output screen :: :: Erase variable :: :: Run command.rmd :: :: Erase command.rmd :: :: :: :: This requires a few more steps, but it still allows me to keep most of my :: code in the program. :: :: :: :: Gary :: :: :: :: From: [email protected] [mailto:[email protected]] On Behalf Of Tom :: Frederick :: Sent: Wednesday, December 14, 2011 11:39 AM :: To: RBASE-L Mailing List :: Subject: [RBASE-L] - RE: Printing: compiled vs. uncompiled :: :: :: :: Paul and Jan, :: :: Everything is recompiled with the 12/12 update. So I put the text of the : PDF :: command code back into the BIT BUTTONs that create the biggest reports. : Make :: no changes to any other print BIT ... and the compiled programs work :: correctly regardless of which print BIT BUTTON is hit. Haven't got a clue :: what is different except no RUN SELECT for two buttons. I did notice I had :: several reports where the sub reports lost the slave tables they used. : That :: was easy to fix, but I will be watching those to find a cause. Appreciate :: your ideas. :: :: :: :: Tom Frederick :: :: President/CEO :: :: Elm City Center :: :: 1314 W Walnut :: :: Jacksonville, IL 62650 :: :: W- 217-245-9504 :: :: F - 217-245-2350 :: :: E - [email protected] :: :: :: :: From: [email protected] [mailto:[email protected]] On Behalf Of Paul : Buckley :: Sent: Tuesday, December 13, 2011 10:07 AM :: To: RBASE-L Mailing List :: Subject: [RBASE-L] - RE: Printing: compiled vs. uncompiled :: :: :: :: Tom, :: :: :: :: This may be a silly question but did you update the compiler and : re-compile :: the application? :: :: :: :: Just thinking, :: :: Paul :: :: :: :: From: [email protected] [mailto:[email protected]] On Behalf Of Tom :: Frederick :: Sent: Tuesday, December 13, 2011 10:37 AM :: To: RBASE-L Mailing List :: Subject: [RBASE-L] - Printing: compiled vs. uncompiled :: :: :: :: I am having problems getting print programs that work in uncompiled v9.1 : 64 :: to also work in compiled v9.1. Latest updates applied. Basic process: : create :: the report, bring it up in a PDF viewer, decide to keep it or erase, if :: erase delete, if keep store it on the network, and update table with info :: needed to retrieve it. For a long time each print command had its own set : of :: commands in a BIT BUTTON. Most of the print command process is identical : so :: I created a list of variables adjusted for each report and stored the : actual :: print process in a table. This line runs the entire process: :: :: :: :: RUN SELECT CmdCode FROM RMD_FILES WHERE CmdName = 'PDF_Reports' :: :: :: :: This works great in the uncompiled version and prints every time : regardless :: of size or number of variables involved. In the compiled version, small : 2-3 :: page reports pop right out, but big complicated reports (6+ pages, lots of :: variables) get stuck and never finish. Immediately run the exact same :: database in uncompiled form and out comes the big report like always. If I :: go back to the original setup of each print command having everything in : one :: place, the compiled version then works correctly. I really like the RUN :: SELECT option because there is only one set of commands to adjust compared :: to many print buttons. Is there some adjustment I need to make for the :: complied version? :: :: :: :: Tom Frederick :: :: President/CEO :: :: Elm City Center :: :: 1314 W Walnut :: :: Jacksonville, IL 62650 :: :: W- 217-245-9504 :: :: F - 217-245-2350 :: :: E - [email protected] :: :: :: :: : : --- RBASE-L ================================================ TO POST A MESSAGE TO ALL MEMBERS: Send a plain text email to [email protected] (Don't use any of these words as your Subject: INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH, REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP) ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: INTRO ================================================ TO UNSUBSCRIBE: Send a plain text email to [email protected] In the message SUBJECT, put just one word: UNSUBSCRIBE ================================================ TO SEARCH ARCHIVES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: SEARCH-n (where n is the number of days). In the message body, place any text to search for. ================================================
