Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Cannot build Project 1

Status
Not open for further replies.

psperry2

Programmer
Nov 7, 2007
141
US
I am on my 3rd day on a Job taking over from someone who was terminated last week. I now have a VFP 7 Project that will not compile.

I am not yet permitted to make any coding changes. I get this error on the compile:

Compiling f:\compcar\companycars\programs\main.prg
l_dNotEmpty = {01/01/1650}
Error in line 1165: Ambiguous date/datetime constant. Use the format:
{^yyyy-mm-dd[,][hh[:mm[:ss]] [a|p]]}

I have attempted to do a Set Century on/Off and this didn't work.

To verify that we have the correct version of the source code, I am supposed to recompile the project and check the size of the executable against the production version.

I am not sure what to do without changing code, to get this project to compile.
 
Can you issues a 'SET STRICTDATE TO 0' command before running the build?

I like work. It fascinates me. I can sit and look at it for hours...
 
Psperry2,

Thanks that worked!

Be careful. It worked with the date that gave rise to the error (1/1/1650). But if you have STRICTDATE set to 0, you open the door to potential problems with other dates.

For example, suppose your application includes code like this:

ldTaxYearStart = {5/4/08}

That will compile without error, but what date do you suppose will be stored? 4th May 2008? 5th April 2008? 5th April 1998? The answer depends on the date and century settings in your code at the time the command executes. Often, you can't tell what those settings will be just by glancing at the code.

It is because of that ambiguity that we are recommended to use the so-called unambiguous date format, and to keep STRICTDATE set to 1.

I'm not saying you will necessarily have those problems, but it is something you need to be aware of this.

Although FatSlug's solution is perfectly valid, a better option in this case would be to change the code as follows:

l_dNotEmpty = {^1650-01-01}

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top