Razzak, hope all is well in Philly.
Looking at this thread and checking the doc's, I have a couple of
questions.
1) What's the difference between #MICRORIM_TIMEOUT and MICRORIM_TIMEOUT.
It appears subtle, but I'm curious if there is some sort of meaningful
difference.
2) Although the scale of TIMER (milliseconds, 1000=1 second) and TIMEOUT
(minutes) are fixed, isn't it important to know the settings related to
TIME, namely the precision, in order to execute reliable TIME-math,
especially when an operand is a constant in the code?
For example:
R>SHO TIME
TIME format HH:MM:SS.SSS
TIME sequence HHMMSS
R>SET TIME FORMAT HH:MM:SS
R>SET VAR vNowStartSeconds = .#NOW ; SET VAR vNowFinishSeconds =
(.vNowStartSeconds + 60000) ; SHO VAR
Variable = Value
Type
----------------------------------------
------------------------------ -------
#DATE = 07/28/09
DATE
#TIME = 11:27:40
TIME
#PI = 3.14159265358979
DOUBLE
SQLCODE = 0
INTEGER
SQLSTATE = 00000
TEXT
#NOW = 07/28/09 11:27:40
DATETIME
vNowStartSeconds = 07/28/09 11:27:40
DATETIME
vNowFinishSeconds = 07/29/09 4:07:40
DATETIME
R>SET TIME FORMAT HH:MM:SS.SSS
R>SET VAR vNowStartMilliseconds = .#NOW ; SET VAR vNowFinishMilliseconds
= (.vNowStartMilliseconds + 60000) ; SHO VAR
Variable = Value
Type
----------------------------------------
------------------------------ -------
#DATE = 07/28/09
DATE
#TIME = 11:28:23.147
TIME
#PI = 3.14159265358979
DOUBLE
SQLCODE = 0
INTEGER
SQLSTATE = 00000
TEXT
#NOW = 07/28/09 11:28:23.197
DATETIME
vNowStartSeconds = 07/28/09 11:27:40.000
DATETIME
vNowFinishSeconds = 07/29/09 4:07:40.000
DATETIME
vNowStartMilliseconds = 07/28/09 11:28:23.064
DATETIME
vNowFinishMilliseconds = 07/28/09 11:29:23.064
DATETIME --*** 1 minute later ...
In the former, the finish time is 60,000 seconds, or 16 hours and 40
minutes, later, at 4:07:40am, the FOLLOWING DAY, because the SET TIME
FORMAT statement defined the precision for time as being in (whole)
seconds. In the latter, the finish time is 60 seconds later
(60000/1000) because the precision is in milliseconds.
I know this is just basic math when it's presented, but I'm sure it has
been, and can often be, a "gotcha" for folks working with TIME-math.
Of course, uniformity in the CFG files, including these FORMAT
definitions should take care of this issue. However, I used the word
"SHOULD". So, a different or additional approach could be some
additional code to check for and handle variations in CFG files - those
kind of things don't ever happen, do they - which would surely include
something like this, taken here from the R> prompt:
SET VAR vTimeFormat = (CVAL('TIME FORMAT'))
SHO VAR vTimeFormat
R>SHO VAR
Variable = Value
Type
----------------------------------------
------------------------------ -------
#DATE = 07/28/09
DATE
#TIME = 11:55:16.952
TIME
#PI = 3.14159265358979
DOUBLE
SQLCODE = 0
INTEGER
SQLSTATE = 00000
TEXT
#NOW = 07/28/09 11:55:17.076
DATETIME
vNowStartSeconds = 07/28/09 11:27:40.000
DATETIME
vNowFinishSeconds = 07/29/09 4:07:40.000
DATETIME
vNowStartMilliseconds = 07/28/09 11:28:23.064
DATETIME
vNowFinishMilliseconds = 07/28/09 11:29:23.064
DATETIME
vTimeFormat = HH:MM:SS.SSS
TEXT
Code could be constructed to evaluate the string assigned to
vTimeFormat, then processing could proceed accordingly.
Not worried about how many angels can dance on the head of a pin, just
trying to share about something that got me a time or two.
Steve in Memphis (who just spent a great extended weekend in Asheville,
including a 4-5 mile run around and atop Black Balsam and Tennent
mountains, appx elevations of 6214ft and 6040ft, respectively; there
were no bars at the top, Verizon or otherwise, but getting there and the
views made it worthwhile.)
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of A.
Razzak Memon
Sent: Saturday, July 25, 2009 1:47pm 13:47
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: TIMER
At 12:26 PM 7/25/2009, Jim Belisle wrote:
>Razzak,
>
>This is my DAT file that opens the main form.
>
>CONNECT Labor
> CLS
>-- Make sure that previously SATTACHed table is detached
> SET ERROR MESSAGE 2038 OFF
> SDETACH Leadall NOCHECK
> SET ERROR MESSAGE 2038 ON
>-- Make sure that the previously DSN-Less Database is Disconnected
> SDISCONNECT ';Driver=R:BASE 7.6 Database Driver (*.rb1);dbq=Sales'
>-- Now Connect the Database Using the DSN-Less Connection
> SCONNECT ';Driver=R:BASE 7.6 Database Driver (*.rb1);dbq=Sales'
>-- Attach Leadall table with proper columns. --
> SATTACH LEADALL USING LEADCODE ALIAS
>CONTACT,COMPNAME,COMPADD,COMPCITY,
>COMPSTATE,COMPZIP,COMPAREA,COMPPHPRE,COMPPHSUF,COMPEXT,sPROMOCAT,sPROMO
I
>D,LEADDATE,DATEANSW,SALEPER,TICDATE,INTEREST,LEADGOOD,NOTES,LEADCODE
> EDIT USING KayParkMainMenu
>-- Make sure that DSN-Less Database is Disconnected
> SDISCONNECT ';Driver=R:BASE 7.6 Database Driver (*.rb1);dbq=SALES'
> DISCONNECT
> EXIT
>RETURN
>
>Would I put this code SET TIMEOUT 60
>before (or just after) the CONNCET LABOR statement or
>before (or just after) the EDIT USING KayParkMainMenu statement?
Jim,
Technically, you can put it anywhere you like. The TIMEOUT settings
is not dependent on the database. This specific setting is related
to R:BASE session.
I would put it at the beginning of the startup .DAT file for obvious
reason.
Very Best R:egards,
Razzak.
