Hi Barbara,

Thanks for your comments. In the end I found the problem.

I have all my tables in a .dbc, to update these I have temp tables with the latest structures. A little program opens the .dbc and uses alter table (add or alter column) to update to latest structures. I also have a views .dbc where all my views are stored. This was causing me a lot of grief.

What I found was that on a couple of views, the field order was slightly different to those of their corresponding tables which caused the field types etc. to get out of sink which would cause an error 107.

I overcame this by writing another little program to recreate the fields in the views in exactly the same order as the tables.


Regards
Doug Johnston


>Doug,
>What happens if you copy your working (development) DBCs into the 'real' site? NOT the data tables, just the DBC. You can run the Validate Data and see if there are any differences between the two systems.
>
>In the future you might look at Stonefield Data Toolkit. It does structure updates superbly.
>
>HTH
>Barbara
>
>>Hi,
>>
>>I have 2 .dbc's for my app, 1 contains all the tables, the other local views of the tables.
>>
>>I have a little program that enables me to change the structure of the tables when necessary. This is all done through the .dbc (alter column add row etc) and every thing seems fine, all the SQL update requirements for the modified tables are either selected or ticked, both .dbc's validate OK, however when editing or adding a new record to the buffered row of the view and issuing tableupdate(.t.), the update fails.
>>
>>The other common denominator is that the fails are from modal forms called by a non modal form with a private datasession.
>>
>>My development system which has had the mods to the .dbc's done by hand works OK, it is just the real (clients) version that plays up.
>>
>>Regards
>>Doug Johnston