OK, I have to be honest. When I first read your message I thought you were nuts. VFP submits queries through ODBC like a million other applications. There should be no difference.

Curiousity got the better of me. You were correct. I'll say it again "YOU ARE CORRECT" - at least based on what I've seen with my own eyes.

Here's what I can tell you so far. I don't have an offical MS position. I'm going to send your script and what I know to a friend of mine that works for MCS. He'll forward it to the SQL Server development team.

OK, VFP uses different query syntaxes (sp?) based on the type of query. For the parameterized query in your example, VFP (through ODBC) is making use of SQL Server sp_executesql system stored procedure. This system stored procedure is used to cache ad-hoc queries. It appears that the problem lies with this system stored procedure.

I used SQL Profiler to capture what was being sent to SQL Server. You sample ends up looking like this:

exec sp_executesql N'update child set parentid = 6, childid = @P1 where childid = @P2 ', N'@P1 float,@P2 float', 2.000000000000000e+000, 2.000000000000000e+000

Notice that the two parameters have been translated to floats. This is because VFP native numeric data type has decimal places. If you submit this query, the FK constraint will be violated EVEN THOUGH THE FK VALUE IS HARD-CODED (this is the part that messes me up)

On the other hand, if you changes the floats to ints:

exec sp_executesql N'update child set parentid = 6, childid = @P1 where childid = @P2 ', N'@P1 int,@P2 int', 2, 2

The FK constraint catches the invalid FK!?!?!?!?!?!?!

When I know something, I'll post it.

-Mike