Thanks for your comments. I should have mentioned that my application must use free tables because there are still FoxPro 2.6 programs working against the same data. So I use one database that holds views only; no stored procedures or default values, or other luxuries offered by using dbc as intended.

I found a workaround (though not the answer to the error message): when I moved the code to append blank to the Init of the form, right after opening the view, instead of waiting for the user to click a Save button, all worked as expected. So I just added a Tablerevert in the Cancel button. The mystery of the syntax error still haunts me, though.

Nancy

>>For creating a new code, I've made a few adjustments to the 1001 Things code to fit my application. A form is called to accept the user's description, apply the appropriate code type and obtain the next code value to be used for the code type. It opens a view of the application's code table, with the view filtered for the specific code type being added. The view is also set as updatable (Send SQL updates, WHERE clause includes key and modified fields). This view is set for optimistic row buffering (3). Here's where my problem appears: When the APPEND BLANK command is issued (and I've verified that the code table view is selected), the program pops up a SYNTAX ERROR. I've suspended prior to the APPEND BLANK to check the environment, etc, and then step through the code with the debugger. Everything looks okay. If I go out to the command window and attempt to BROWSE or EDIT the view, I get a syntax error. I've also cancelled the program, closed all, cleared all, and opened the view
>>from the command window. I can APPEND BLANK there.
>>
>>The form that is called to add a new code uses the default data session. The formset from which this form is called uses a private data session.
>>
>>What am I missing? Any help you can offer will be greatly appreciated!
>
>The only thing I see as dubious is any code in the default value of the key for the underlying table. You may have trouble if Set("Database") is on a different dbc at the moment (which may have a SP with the same name but different parameters etc). One thing you can try is to Set Database To {appropriate one} before doing the Append Blank, or doing an Insert Into (view) (keyfield) value (newid()) - or whatever your function to get the key is - instead of Append Blank. That way the default won't fire, because it fires only when you insert a record without the value for that field. This is not entirely kosher, because then you're calling a (supposedly) stored procedure from outside of the DBC, and tearing down the whole idea of having stored procedures, but it may serve to understand what's going on.