>>>>May be I am missing something, but why you try MODIFY View? Just repeate: create view ... with the new definition. It will replace previous view definition in the DAtabase.
>>>
>>>The view is paramaeterized. Stepping through the view designer takes longer too.
>>
>>Huh? Why does parameterization present a problem? Can you use something like this?

>>local array ladatabases[5]
>>ladatabases[1] = 'Database1'
>>ladatabases[2] = 'Database2'
>>ladatabases[3] = 'Database3'
>>ladatabases[4] = 'Database4'
>>ladatabases[5] = 'Database5'
>>lcsqlstr = space(0)
>>for lxx = 1 to alen(ladatabases)
>>   lcsqlstr = [create sql view MySQLView] + transform(lxx) + [ remote ] +;
><b>      [connection MyDSNName ] + ; </b>
>>      [select tab1.field1, tab2.field2 from ] + ladatabases[lxx] + [.dbo.Table1 tab1, ] +;
>>      ladatabases[lxx] + [.dbo.Table2 tab2] + ;
>>      [ where tab1.PK = tab2.FK and tab1.field2 = ?lusomevalue ] +;
>>      [order by 2]
>>      &lcsqlstr
>>endfor

>>You could also add the appropriate DBSetProp() commands after the macro expansion.
>>
>>HTH.
>
>See correction above in bold

Maybe I haven't explained this properly, Larry. First, the reason I have these views is for testing purposes. No updates are made, it's data that used to initialize a automation server. There are a number of tables involved, each having different parameters, both in terms of number and type. The parameters are used to retrieve the values in code. No interaction with the keyboard. Therefore, the name of the parameter becomes important. Therefore, I would have to retrieve that as well. Since there's a lot of code involved in testing, if I were to change the parameter names, I'd have to make changes in the code as well.

What works and is simpler is simply to modify the view, do something to change it, then change it back and save the changes. The view then works properly. I'm just trying to find a way to automate the process.