Roxanne,
What happened to us was this.

1. The SDT's friendly behavior caused every view to try and call the NewID function on it's own. As a side benefit it prevented some of the framework's code from firing because the IF statement, that protects SetFldState command, never tested true. We couldn't see what everyone else was getting.

2. The minute we cleaned up our views we could now duplicate the error.

3. The problem seems to lie with the SetFldState function. This function makes the base table belief that an appended record has NOT been changed. During an update this seems to cause the base table to try and establish default values.
We could duplicate this error by appending a record into a view changing the primary key to some absurd number using the SetFldState function and then moving the pointer. When we checked the base table the NewID function had fired and a valid ID had been generated. If we didn't use SetFldState the NewID function did not fire.

The hackers guide has a huge warning about the SetFldState function. They seem to think it doesn't behave reliably.

From the Hackers Guide
"SetFldState() is another story. The docs say it changes the status of a field or record. That it does. But the docs also say that the change affects what FoxPro attempts to update-that is, by changing the status of a field from "changed" to "unchanged", you can keep FoxPro from updating the real record underneath. Doesn't work for us. We can SetFldState() all we want and FoxPro still updates the original table with all the changes we've made."

So this does seem to be a framework issue. I'm still thinking about possible solutions.

I hope this helps,
Bill