Well if the cat doesn't have a local database engine, it is inferior.

>Somehow I think that if there was only one programmer in the world there would be more than one way to "skin a cat"! :)
>
>
>>I don't care that somebody has different opinions than me... I just can't stand when people take the "My way is better than your's" approach while including phrases like ".NET folks up here don't get it". Not everybody needs change tracking or NULL dates or a local database engine.
>>
>>>I'm betting it's lonely.
>>>
>>>>What's it like on your pedestal, Walter?
>>>>
>>>>>Appart form the date issues, NULLs are used in scientific databases a lot as indicator that data is missing or not applicable. Calculations like AVG(), COUNT(Fieldname), STD() etc do ignore NULL values and therefore NULL values are an important aspect of database design.
>>>>>
>>>>>Not being able to set null values in your application framework is a big huge gap and severely limits you in writing scientifical database applications.
>>>>>
>>>>>As you and I know dynamic SQL is the answer for implementing change tracking with conflict control as well as handling NULL values elegantly. It absolutely shocking to see most .NET folks up here don't get it and can't see the transparancy and ease of use of VFPs implementation of the update mechanism of remote views THAT HAS BEEN THERE FOR AT LEAST A DECADE, and still gospel about stored procedures as the way to go. Argghhh. It is like living in the stone age. Are we never going to learn the lesson?
>>>>>
>>>>>Sure I can see cirumstances where stored procedures are a suitable implementation, but to gospel about it as the starting point for all applications does not prove of any knowledge and understanding regarding this matter.
>>>>>
>>>>>Walter,
>>>>>
>>>>>
>>>>>
>>>>>>I do think the issue of NULL dates has not been answered satisfactorily- apart from by Bonnie B who described a mechanism to use a "date a long time ago" as a placeholder for blank. I know the same technique is used by some VFP people who have upsized local tables to SQL Server and discovered the lack of a blank date, but that was usually because it was easier to handle the date placeholder than to rewrite the code to handle NULLs. I'd be interested to see whether NET converts from other places than VFP are using NULLs or placeholders. If they're using NULLs, I'd imagine they're also using change tracking to overcome the issue you have described.