Max --

With this being an aspect of a program rather than a one-time update, I'd have to agree that modifying the programs to get them in sync is a necessary first step.

The date data type does provide a lot of valuable services. You can do date arithmetic (first day of week, a month ago, first day of month, QUARTER, Day of Week) function that come natively with VFP or simple library routines that have been noted here at UT. Storing dates as characters is OK for storage purposes, but still runs into the problems of comparison noted earlier.

To update the original file, you can simple add the date field in the table designer. SET STRICTDATE TO 0. Then REPLACE ALL dNewDate WITH CTOD (cOldDate). Then, you can change the input form to use the new field, and then change all references to the old date field elsewhere to the new date field.

Best wishes!

Jay

>Thanks again Jay, it looks like I've got quite a bit of work ahead of me as the program I am working on is an addition to an existing program and they are supposed to work together so I'm going to have to restructure that original program as that's where the field is generated from. Hopefully I can get it all working...hopefully! :)
>Thanks
>Max
>
>>> It works well to use the same data type to store the same kind of >information. Everytime a transformation takes place from one data type to another, unanticipated things can occur.
>
>>> For example, let's say that you've entered "12/9/2001" in the character field. We understand that date perfectly well. But, when VFP transforms a date field with the value {12/9/2001} into a string, it comes out "12/09/2001" (maintaining a constant field width). And, "12/09/2001" is not equal to "12/9/2001" when compared as character strings.
>
>>> At this point, I'd suggest the following. Make a backup of your data! Then, work from the code we're talking about. Take off the DTOC() function on the line you got the error. Then, try running the code.
>
>>> Check the results and see if you get what you intend. If not, you may be able to make mods, if they're only a few, by hand.
>
>>> There's so much to get a handle on, isn't there? We've all been there. I couldn't help noticing some issues, including the one here, that I would avoid in creating a database design. A couple references which may give a boost -- Michael Antonovich describes relational database design in an article here -- article #180. Also, a good intro book is Relational Database Design for Mere Mortals by Hernandez. I can speak from the school of hard knocks that a good database design saves a lot of grief down the road<g>.
>
>>> Jay