It IS an option, unfortunately due to limitations in the VFP OLEDB provider, it doesn't always work!

Hey, Kevin...

Can you elaborate? What specific limitations are you referring to?

I had previously done a test of a simple UPDATE against a table, and got the "Dynamic SQL generation" error. At the time my test table had an integer key index, but it was a regular index and not a Primary or Candidate.

But when I change it ot a primary (or candidate), the update works fine.

So I'll paraphrase my question - so long as one is utilizing primary/candidate index definitions in VFP, would you always expect the following to work?

OleDbDataAdapter oDSAdapter = new OleDbDataAdapter("select * from client",oConn);
DataSet oDs = new DataSet();
oDSAdapter.Fill(oDs);
OleDbCommandBuilder oCmdBuilder = new OleDbCommandBuilder(oDSAdapter);
oDs.Tables[0].Rows[0]["descript"] = "Making a manual change";
oDSAdapter.Update(oDs,oDs.Tables[0].TableName);

It works for me, but was just curious if there were any 'gotchas' you might be aware of. I'm using the most current provider - is there any chance the limitations you referred to are based on older versions of the provider?

If it is clean, there's an existing white paper on the VFP OLE DB Provider stating that a developer must manually assign UPDATE statements. (I believe the information was based on an older version of the Provider).

Previously I was under the impression that one always had to do updates manually with the VFP provider, but if that isn't true (so long as primary keys are used), then the only significant limitation I'm aware of (using just the provider) is that you can't get a VFP stored proc to return a result set directly into a dataset.

(With the increase in # of people who are using vfp with .net, I'm trying to get a handle on the actual issues with the provider).


Thanks,
Kevin