>>
If you change the name of a column that you SP references it is just as dead...

Every try opening an invalid view definition? With a SP, all I need to do is modify the proc. Often, with an invalid view def, I might not be able to open the view...

So no, you are not JUST as dead....




>If you change the name of a column that you SP references it is just as dead...
>
>>If you change the name of a column that your view references, your view is dead...
>>
>>RV's are bad... if you really want to do the job right...don't use RV's. There are too many areas where RV's fall short and leave you vulnerable to come to any other conclusion...
>>
>>
>>
>>
>>>John, isn't that only true if your view has SELECT * ?
>>>
>>>BOb
>>>
>>>
>>>>Yet another knock agains RV's..
>>>>
>>>>How about times when the underlying schema changes????
>>>>
>>>>Bang.... your remote view is broken!!!
>>>>
>>>>Too much a PITA...
>>>>
>>>>
>>>>
>>>>
>>>>>>I am a member of a team that successfuly deployed a VFP/SQL application that was migrated from an existing FPW application. Here are the stats:
>>>>>>
>>>>>>500+ users (simultaneous)
>>>>>>100+gb database
>>>>>>24x7
>>>>>>Stored Proc - Driven
>>>>>>No DBC or Remote View Use - use SPT and ADO instead....
>>>>>
>>>>>John, I am curious to hear about this project. That is a heck of a lot of data- what was it for?
>>>>>
>>>>>>Remote views do not scale....period.
>>>>>
>>>>>This is definitely true, and partly for reasons that you might not even be aware of. ON top of the fact that RVs do not take advantage of precompiled SQL, accessing a remote view (like accessing a local view) locks, for a brief period of time, the record in the dbc that holds the view definition, and a heavily accessed system will cause contention that cannot be easily trapped, and instead throws error 1709, and renders a form or procedure useless.