Currently we are accessing data through local p-views. We can switch to CA for any new development, since MereMortals framework we're using allows to work with CA.

But I'm still a little bit confused with all your answers.

My first question is: can we use date field in our VFP database? Is it wise to use this field as a date field (because from the business requirements point of view the field is really a date field). How easy it is to upsize to SQL Server if we define the field as date in our VFP database?

I already understood, that we should not use ttod function if we want compatibility with SQL Server. So, how exactly should we write our filter condition? If we switch to date field, we would use datefield = ?vp_dDate. If we keep it as a datetime, what should we use?

I haven't yet used CA, but I'm ready to use them, if it makes our application more scalable. But this question needs to be discussed among our developers and we all should agree on the specific approach. I was following the current programming way we have here in place so far.

>You can map datetime field to a date in a view so I don't see a difference between date and datetime as long as data is accesed through a view or CA. The ttod(datetimefield) = ? vp_Date in the WHERE clause doesn't translates nicely to SQL Server, though.
>
>
>>We had a discussion today about date vs. datetime field and I want to get your valuable input.
>>
>>We currently use Visual FoxPro native data as our back end but we may go to SQL Server in the future. Is it wise to have all date fields defined as datetime and therefore use ttod(datetimefield) = ? vp_Date in our p-views and index on ttod(datetimefield)? Or should we use date field if there is no sense in datetime field from the user's perspective?
>>
>>Also I think I read it here recently that SQL Server is going to introduce DATE field. Is it a rumor I'm just starting or a fact?