Strange datetime() behaviour.

[Bryan - Gendev]

In my main app I keep a log file as events occur. I use the following line in the called routine

STRTOFILE(TTOC(DATETIME(),2)+'  ' +cMessageText+CHR(013)+CHR(10),(myPWLog),.T.)

A user has just sent me the last few lines of his log file -

10:57:15 PM *** step2_proj_ini_entries with 2
10:57:15 PM Select next Action - Filter Actions or Project Wide Options
10:57:15 PM Type of run 2
10:57:16 PM 100%
10:57:16 PM End scan 100%
9:25:23 AM LF Donego = F
9:25:23 AM Log File View

How could the time stamp be so wrong? I can't ask the user if his system clock changed at that time.

Any ideas?

Thanks

GenDev

 

[Dan Freeman]

Leftovers from a previous day?

 

[Bryan - Gendev]

Thnaks Dan

The log is re written when my app starts up... in main.prg

myPWLog = (mylogpath)+'pathwiz.log'

If File(myPWLog)
	Delete File (myPWLog)
Endif

 

[EzLogic]

So, what's wrong with the log.

looks like it stopped logging at 10ish PM and started again at 9:25am'ish

if you had the date, it would better tell to see if same day time changed, it was a different date.

Ez Logic
Michigan

 

[mm0000]

If the logs are re-written on start-up - is it possible the user did not quit the application the previous day and continued working with the application at 9.25am on the next day.

 

[Bryan - Gendev]

It is possible that the user left my app running overnight and asked to see the log the next morning.

As I have STRTOFILE(TTOC(DATETIME(),2)+' ' +cMessageText+CHR(013)+CHR(10),(myPWLog),.T.) at present how could I add the YEAR to the time stamp please?

Thanks

Gendev

 

[stefanodam78]

last modify date of file on filesystem?

 

[Olaf Doschke]

YEAR(DATE()) gives the year, you could also use TTOC(DATETIME(),3) or TTOC(DATETIME(),4) instead of TTOC(DATETIME(),2) o include the year. Or simply TTOC(DATETIME())

That won't help you find out, if a user kept your app running over night, though.

Bye, Olaf.

 

[Olaf Doschke]

Well, the YEAR won't help, but including the date in the log file, of course.
Still, isn't it simpler to assume the date is the next day, if the time changed "back" instead of assuming the system time changed?

Bye, Olaf.

 

[Mike Lewis]

GenDev,

One thing that hasn't been mentioned: Can you communicate with the user? Can you ask him if he was working up to 11 pm one night, and started work around 9.30 am the following morning? If the answer is Yes, that would at least comfirm the hypothesis that the time has clicked round to the next day.

Assuming that's the case (and it does seem highly likely), the easist solution is to use TRANSFORM() with the datetime:

STRTOFILE([b]TRANSFORM(DATETIME())[/b] +'  ' +cMessageText+CHR(013)+CHR(10),(myPWLog),.T.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

TRANSFORM(DATETIME()) has the same result as TTOC(DATETIME()), just takes a bit longer. The advantage of TRANSFORM() is, it takes any type as parameter to transform into a string, but specialised functions as TTOC() are faster, as they are specialised. Another advantage of TRANSFORM() is the use of format strings etc, all the additional parameter you have.

It may depend a little on your (V)FP version, but I think TRANSFORM also is around for quite a long time.

To round this up SET CENTURY ON/OFF, SET HOURS 12/24, SET DATE BRITISH/AMERICAN/GERMAN/FRENCH and some more SET Commands (MARK,SEPARATOR) functions influence how TTOC(),DTOC() or TRANSFORM() convert dates into strings. The easy solution to get what the user is used to by windows regional system settings is SET SYSFORMATS ON.

Bye, Olaf.

 

[Bryan - Gendev]

Thanks Mike and Olaf

I have asked the user about an overnight running of the program - no response yet.

Also erroneously stated YEAR when I meant DATE

Thanks

Gendev

 

[Olaf Doschke]

Okay, that explains it.

If you need your log to restart and do other daily initialisations that shouldn't be missed by keeping the application running over night, you could specify it to quit near midnight, for example with a timer having a Timer event:

If Time()<'00:01:00'
   QUIT
Endif

That would quit the app, if it's between 0:00 AM and 0:01 AM. The timer would need to run at least once a minute, better more often to not miss the interval between 00:00:00 and 00:01:00 of course.
And of course that would also quit the app, if you restart it before 00:01:00.

Bye, Olaf.

 

[Mike Lewis]

That would quit the app

Yes, but several problems could arise from issuing QUIT like that.

For example, suppose the user has a form open, and the form has code in its Destroy or QueryUnload to test for unsaved edits. The form might issue a prompt to deal with that situation, but nobody will be present to act on the prompt. Or the form might itself decide to save the edits, but the edits might fail a validation check.

What if the application is in the middle of some time-consuming operation, such as an overnight data transfer? What if one particular lengthy command, such as a very slow SELECT, is in operation? In that case, the timer wouldn't fire until the command has finished, so you would lose your one-minute window (although there are no doubt other ways of dealing with that). Or what if a transaction is in progress?

Or what if one or more modal forms is open, or you are in a READ EVENTS? In those cases, the only thing the QUIT would do is to display the "cannot quit Visual FoxPro" message.

An alternative way of forcing a program to close might be as follows:

1. Loop through all data sessions, rolling back the current transactions.

2. In each data session, loop through all work areas, reverting any unsaved edits.

3. Execute the following code, which kill VFP stone dead:

DECLARE Integer ExitProcess IN WIN32API 
ExitProcess()

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

You're right, Mike, I didn't thought of that, I thought of an application in idle state at midnight, but perhaps it's even more likely a user left a form open.

But indeed READ EVENTS is a state you surely can end with QUIT, only modal forms or forms disallowing release of the form with QueryUnload, open Transactions and some other things might hinder a quit.
I'd say it's better in such a case to leave the application open than to issue an ExitProcess().

You might do more than QUIT, eg loop through the array created by ASESSIONS, then ROLLBACK any started transactions, TABLEREVERT on any buffered workarea, then try QUIT.

The best would be an application which is designed to never be in an indefiniate modal state. You can't enforce that fully, but you have more options than to ExitProcess.

It's just an idea anyway. An even better approach might be to give the user a motivation to start the application new each day, eg a cartoon or quote of the day message at startup might work wonders.

Bye, Olaf.

 

[Mike Lewis]

I agree completely, Olaf. In any case, forcing the application to close is not a solution to the original problem. The answer is to fix the date issue in the log file, as we have indicated.

(Also, the user might have a genuine reason for working beyond midnight.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads